From report at bugs.python.org  Wed Jun  1 00:01:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 May 2011 22:01:44 +0000
Subject: [issue12229] Remove unused variable in bufferedio.c
In-Reply-To: <1306877368.88.0.968451674352.issue12229@psf.upfronthosting.co.za>
Message-ID: <E1QRX0Q-0003ei-ON@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 549cb21a8757 by Victor Stinner in branch 'default':
Close #12229: Remove an unused argument of _bufferedreader_peek_unlocked(),
http://hg.python.org/cpython/rev/549cb21a8757

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Jun  1 00:02:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 May 2011 22:02:11 +0000
Subject: [issue12229] Remove unused variable in bufferedio.c
In-Reply-To: <1306877368.88.0.968451674352.issue12229@psf.upfronthosting.co.za>
Message-ID: <1306879331.27.0.870156724052.issue12229@psf.upfronthosting.co.za>


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

I applied your fix, thanks.

----------

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

From report at bugs.python.org  Wed Jun  1 00:11:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 May 2011 22:11:26 +0000
Subject: [issue12225] current tip doesn't build without mercurial installed
In-Reply-To: <1306854977.0.0.17464717036.issue12225@psf.upfronthosting.co.za>
Message-ID: <E1QRX9p-0004NN-13@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 435eec7b41f0 by Ralf Schmitt in branch 'default':
disable ASDLGEN if hg won't work, or if python is not installed.
http://hg.python.org/cpython/rev/435eec7b41f0

----------
nosy: +python-dev
resolution: duplicate -> fixed

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

From report at bugs.python.org  Wed Jun  1 00:48:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 May 2011 22:48:46 +0000
Subject: [issue12230] test_subprocess.test_pass_fds() failed on x86 Tiger 3.x
In-Reply-To: <1306882126.33.0.416500122697.issue12230@psf.upfronthosting.co.za>
Message-ID: <1306882126.33.0.416500122697.issue12230@psf.upfronthosting.co.za>


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

test_subprocess.test_pass_fds() failed on x86 Tiger 3.x:

test test_subprocess failed -- Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_subprocess.py", line 1296, in test_pass_fds
    "fd to be closed passed")
AssertionError: {9} is not false : fd to be closed passed

http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x/builds/2671/steps/test/logs/stdio

The pass_fds parameter of Popen constructor was introduced in #6559.

----------
components: Library (Lib), Tests
keywords: buildbot
messages: 137396
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: test_subprocess.test_pass_fds() failed on x86 Tiger 3.x
versions: Python 3.3

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

From report at bugs.python.org  Wed Jun  1 00:53:18 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 31 May 2011 22:53:18 +0000
Subject: [issue12225] current tip doesn't build without mercurial installed
In-Reply-To: <1306854977.0.0.17464717036.issue12225@psf.upfronthosting.co.za>
Message-ID: <1306882398.03.0.535494732639.issue12225@psf.upfronthosting.co.za>


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

Check for python executable is not complete . What about if system has only version 3+ installed ?

----------
nosy: +rpetrov

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

From report at bugs.python.org  Wed Jun  1 00:57:12 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 31 May 2011 22:57:12 +0000
Subject: [issue12225] current tip doesn't build without mercurial installed
In-Reply-To: <1306882398.03.0.535494732639.issue12225@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=b4bR6GBFGjR_MjbywCUGRODYJgQ@mail.gmail.com>


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

2011/5/31 Roumen Petrov <report at bugs.python.org>:
>
> Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:
>
> Check for python executable is not complete . What about if system has only version 3+ installed ?

Then hg can't possibly be installed either.

----------

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

From report at bugs.python.org  Wed Jun  1 01:08:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 May 2011 23:08:55 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
	__init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <E1QRY3S-0007nK-Ej@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0f2714e49583 by Victor Stinner in branch '3.2':
Close #12085: Fix an attribute error in subprocess.Popen destructor if the
http://hg.python.org/cpython/rev/0f2714e49583

New changeset 71dfd8cf4bf5 by Victor Stinner in branch 'default':
(Merge 3.2) Close #12085: Fix an attribute error in subprocess.Popen destructor
http://hg.python.org/cpython/rev/71dfd8cf4bf5

New changeset 26ea0a46aadd by Victor Stinner in branch '2.7':
Close #12085: Fix an attribute error in subprocess.Popen destructor if the
http://hg.python.org/cpython/rev/26ea0a46aadd

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Jun  1 01:17:29 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 31 May 2011 23:17:29 +0000
Subject: [issue12225] current tip doesn't build without mercurial installed
In-Reply-To: <1306854977.0.0.17464717036.issue12225@psf.upfronthosting.co.za>
Message-ID: <1306883849.59.0.76050672522.issue12225@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

As the OP notes, autoconf needs to be run to update `configure` and those changes needs to be pushed as well so that 'configure.in' and 'configure' are in sync again.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Wed Jun  1 01:21:36 2011
From: report at bugs.python.org (Dave Rawks)
Date: Tue, 31 May 2011 23:21:36 +0000
Subject: [issue2466] os.path.ismount doesn't work for mounts the user doesn't
	have permission to see
In-Reply-To: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za>
Message-ID: <1306884096.77.0.056511561609.issue2466@psf.upfronthosting.co.za>


Dave Rawks <dave at pandora.com> added the comment:

Confirm this problem exists in 2.7 as well.

----------
nosy: +drawks
versions: +Python 2.7

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

From report at bugs.python.org  Wed Jun  1 01:56:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 May 2011 23:56:14 +0000
Subject: [issue12231] regrtest: add -k and -K options to filter tests by
	function/file names
In-Reply-To: <1306886173.49.0.536773734975.issue12231@psf.upfronthosting.co.za>
Message-ID: <1306886173.49.0.536773734975.issue12231@psf.upfronthosting.co.za>


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

Attached patch adds -k/--func-regex and -K/--file-regex options to filter tests by function/file names. It modifies makeSuite() and getTestCaseNames() functions of unittest.loader to add an optional filter argument: callback taking a function name as argument and returning False if the test should be ignored. You can use the new options more than once and their argument are regular expressions (case insensitive).

Examples:

- "./python -m test -k subprocess -K pass_fds" runs only 1 function of 1 file: test_subprocess.test_pass_fds()
- "./python -m test -k os$" runs 1 file: test_os
- "./python -m test -K codecencoding" runs 6 files: test_codecencodings_cn, test_codecencodings_hk, test_codecencodings_iso2022, test_codecencodings_jp, test_codecencodings_kr, test_codecencodings_tw

----------
components: Tests
files: regrtest_regex.patch
keywords: patch
messages: 137402
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest: add -k and -K options to filter tests by function/file names
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22216/regrtest_regex.patch

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

From report at bugs.python.org  Wed Jun  1 02:01:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 01 Jun 2011 00:01:07 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
	__init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <E1QRYry-0002ZU-IB@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 07b43607a905 by Victor Stinner in branch '2.7':
Issue #12085: Fix test_subprocess for my previous commit
http://hg.python.org/cpython/rev/07b43607a905

----------

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

From report at bugs.python.org  Wed Jun  1 02:05:43 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 01 Jun 2011 00:05:43 +0000
Subject: [issue12231] regrtest: add -k and -K options to filter tests by
	function/file names
In-Reply-To: <1306886173.49.0.536773734975.issue12231@psf.upfronthosting.co.za>
Message-ID: <1306886743.09.0.377235902829.issue12231@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/issue12231>
_______________________________________

From report at bugs.python.org  Wed Jun  1 02:08:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 01 Jun 2011 00:08:29 +0000
Subject: [issue12221] segfaults with unexpanded $Revision$ id's in release
	candidate tarballs
In-Reply-To: <1306831663.83.0.751518346555.issue12221@psf.upfronthosting.co.za>
Message-ID: <E1QRYz5-0002xQ-8Z@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9c1116e582e3 by Benjamin Peterson in branch '2.7':
simply use the Python version for pyexpat.__version__ #12221
http://hg.python.org/cpython/rev/9c1116e582e3

New changeset 9c23efa3f5c7 by Benjamin Peterson in branch '3.1':
simply use the Python version for pyexpat.__version__ #12221
http://hg.python.org/cpython/rev/9c23efa3f5c7

New changeset f2f74b8d6767 by Benjamin Peterson in branch '3.2':
merge 3.1 (#12221)
http://hg.python.org/cpython/rev/f2f74b8d6767

New changeset d1291e048163 by Benjamin Peterson in branch 'default':
merge 3.2 (#12221)
http://hg.python.org/cpython/rev/d1291e048163

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

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

From report at bugs.python.org  Wed Jun  1 02:11:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jun 2011 00:11:40 +0000
Subject: [issue12231] regrtest: add -k and -K options to filter tests by
	function/file names
In-Reply-To: <1306886173.49.0.536773734975.issue12231@psf.upfronthosting.co.za>
Message-ID: <201106010211.25579.victor.stinner@haypocalc.com>


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

> Attached patch adds -k/--func-regex and -K/--file-regex options to filter
> tests by function/file names.

We need maybe a third option to filter tests by their class name. And we need 
also maybe the opposite option: exclude tests matching a regex. Another 
proposition: --include and --exclude options using the following format:

<file regex>:<class regex>:<function regex>

Each field is optional, examples:

--include "test_subprocess::leak" ignores test_leak function of 
test_subprocess file
--include "codecencoding::" runs the 6 test_codecencoding* files
--include "test_subprocess:^C:" runs only the tests of the io module (not the 
_pyio module)
- etc.

Problem: --exclude (-x) option is already used.

----------

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

From report at bugs.python.org  Wed Jun  1 02:13:58 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 01 Jun 2011 00:13:58 +0000
Subject: [issue12221] segfaults with unexpanded $Revision$ id's in release
	candidate tarballs
In-Reply-To: <1306831663.83.0.751518346555.issue12221@psf.upfronthosting.co.za>
Message-ID: <1306887238.45.0.589895631032.issue12221@psf.upfronthosting.co.za>


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

I've fixed the pyexpat.__version__ from segfaulting. The other ones are harmless and can be removed later.

----------
priority: release blocker -> normal

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

From report at bugs.python.org  Wed Jun  1 02:27:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jun 2011 00:27:33 +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: <1306888053.96.0.97419028468.issue8407@psf.upfronthosting.co.za>


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

Cool, "x86 FreeBSD 6.4 3.x" is green for the first time since a long time, thanks to my commit 29e08a98281d (test_signal doesn't check signal delivery order).

----------

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

From report at bugs.python.org  Wed Jun  1 02:31:40 2011
From: report at bugs.python.org (Thanh Ly)
Date: Wed, 01 Jun 2011 00:31:40 +0000
Subject: [issue12232] embedded python import cmath
In-Reply-To: <1306888300.23.0.381408538703.issue12232@psf.upfronthosting.co.za>
Message-ID: <1306888300.23.0.381408538703.issue12232@psf.upfronthosting.co.za>


New submission from Thanh Ly <thanh.l at ntlworld.com>:

Calling Python script from C/C++ seems to work fine until using 'import cmath' causing the C/C++ application to hang. Other modules can be imported such as 'math'.

----------
messages: 137408
nosy: Thanh Ly
priority: normal
severity: normal
status: open
title: embedded python import cmath
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Wed Jun  1 03:00:00 2011
From: report at bugs.python.org (John O'Connor)
Date: Wed, 01 Jun 2011 01:00:00 +0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1306890000.83.0.251870586061.issue2091@psf.upfronthosting.co.za>


John O'Connor <tehjcon at gmail.com> added the comment:

It seems to me that adding the proper check is a good idea. It also may not be obvious to some that 'U' is now more or less an alias for 'r'. I have updated the patch so that it at least applies.

I also removed a redundant `reading = 1`

----------
nosy: +jcon
Added file: http://bugs.python.org/file22217/issue2091-2.patch

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

From report at bugs.python.org  Wed Jun  1 03:20:37 2011
From: report at bugs.python.org (John O'Connor)
Date: Wed, 01 Jun 2011 01:20:37 +0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1306891237.86.0.297678962129.issue1152248@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
nosy: +jcon

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

From report at bugs.python.org  Wed Jun  1 03:39:53 2011
From: report at bugs.python.org (Austin Howard)
Date: Wed, 01 Jun 2011 01:39:53 +0000
Subject: [issue12233] Lists in class objects not independent
In-Reply-To: <1306892393.27.0.721356313159.issue12233@psf.upfronthosting.co.za>
Message-ID: <1306892393.27.0.721356313159.issue12233@psf.upfronthosting.co.za>


New submission from Austin Howard <austin1howard at gmail.com>:

When creating a class which contains elements that are lists, the lists for different instances of the class are not independent. Calling
self.mylist.append(3)
inside a class method will update the mylist variable for *all* instances of the class, not just the current instance. Attached is a script which demonstrates this behavior.

----------
components: Interpreter Core
files: python_bug.py
messages: 137410
nosy: austin1howard
priority: normal
severity: normal
status: open
title: Lists in class objects not independent
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file22218/python_bug.py

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

From report at bugs.python.org  Wed Jun  1 03:43:42 2011
From: report at bugs.python.org (John O'Connor)
Date: Wed, 01 Jun 2011 01:43:42 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1306892622.5.0.382111181868.issue11197@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
nosy: +jcon

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

From report at bugs.python.org  Wed Jun  1 03:46:30 2011
From: report at bugs.python.org (John O'Connor)
Date: Wed, 01 Jun 2011 01:46:30 +0000
Subject: [issue8578] PyWeakref_GetObject
In-Reply-To: <1272635901.2.0.350528689181.issue8578@psf.upfronthosting.co.za>
Message-ID: <1306892790.96.0.0124426333827.issue8578@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
nosy: +jcon

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

From report at bugs.python.org  Wed Jun  1 03:52:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 01 Jun 2011 01:52:21 +0000
Subject: [issue12221] segfaults with unexpanded $Revision$ id's in release
	candidate tarballs
In-Reply-To: <1306831663.83.0.751518346555.issue12221@psf.upfronthosting.co.za>
Message-ID: <E1QRabb-0000Ry-S1@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f3553d5083f8 by Benjamin Peterson in branch 'default':
remove __version__s dependent on subversion keyword expansion (closes #12221)
http://hg.python.org/cpython/rev/f3553d5083f8

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

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

From report at bugs.python.org  Wed Jun  1 04:20:58 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Jun 2011 02:20:58 +0000
Subject: [issue12233] Lists in class objects not independent
In-Reply-To: <1306892393.27.0.721356313159.issue12233@psf.upfronthosting.co.za>
Message-ID: <1306894858.96.0.0682578792485.issue12233@psf.upfronthosting.co.za>


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

Sorry, that is correct behavior for class variables.

To get your intended effect (independent lists) do the list instantiation inside the __init__ method.

----------
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Wed Jun  1 04:24:49 2011
From: report at bugs.python.org (John O'Connor)
Date: Wed, 01 Jun 2011 02:24:49 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1306895089.63.0.346127872875.issue10399@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
nosy: +jcon

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

From report at bugs.python.org  Wed Jun  1 04:32:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 01 Jun 2011 02:32:07 +0000
Subject: [issue8578] PyWeakref_GetObject
In-Reply-To: <1272635901.2.0.350528689181.issue8578@psf.upfronthosting.co.za>
Message-ID: <E1QRbE6-0002pN-2j@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a856be6688a6 by Benjamin Peterson in branch '3.2':
be extra careful with a borrowed reference when the GIL could be released (closes #8578)
http://hg.python.org/cpython/rev/a856be6688a6

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Jun  1 06:06:08 2011
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Wed, 01 Jun 2011 04:06:08 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1306901168.96.0.571984662067.issue7978@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

I don't think we should block signals - we can sleep on select for about forever.

----------

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

From report at bugs.python.org  Wed Jun  1 07:10:24 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 01 Jun 2011 05:10:24 +0000
Subject: [issue11822] Improve disassembly to show embedded code objects
In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za>
Message-ID: <1306905024.0.0.344222937254.issue11822@psf.upfronthosting.co.za>


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

Note that Yaniv Aknin (author of the Python's Innards series of blog posts) has a recursive dis variant that may be useful for inspiration:

https://bitbucket.org/yaniv_aknin/pynards/src/c4b61c7a1798/common/blog.py

As shown there, this recursive behaviour can also be useful for code_info/show_code.

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

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

From report at bugs.python.org  Wed Jun  1 07:13:15 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 01 Jun 2011 05:13:15 +0000
Subject: [issue12230] test_subprocess.test_pass_fds() failed on x86 Tiger 3.x
In-Reply-To: <1306882126.33.0.416500122697.issue12230@psf.upfronthosting.co.za>
Message-ID: <1306905195.35.0.843286912912.issue12230@psf.upfronthosting.co.za>


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

Could this be related to http://bugs.python.org/issue6559#msg123958?
Or Issue10826?

----------
nosy: +rosslagerwall

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

From report at bugs.python.org  Wed Jun  1 07:23:45 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 01 Jun 2011 05:23:45 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1306905825.79.0.479211016745.issue12226@psf.upfronthosting.co.za>


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

I'm +0 on changing 2.6. Many people use setuptools or distribute, so the impact of this change was higher if those were modified instead of modifying 2.6 - in particular since few people are expected to pick up these security releases, anyway.

----------

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

From report at bugs.python.org  Wed Jun  1 08:15:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:15:27 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1306908927.22.0.272264931246.issue1621@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.5

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

From report at bugs.python.org  Wed Jun  1 08:15:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:15:47 +0000
Subject: [issue1669349] make install fails if no previous Python installation
Message-ID: <1306908947.95.0.405321431278.issue1669349@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.5

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

From report at bugs.python.org  Wed Jun  1 08:17:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:17:24 +0000
Subject: [issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
	`MAP_ANONYMOUS' undeclared
In-Reply-To: <1215043666.75.0.766151712273.issue3265@psf.upfronthosting.co.za>
Message-ID: <1306909044.08.0.853775331779.issue3265@psf.upfronthosting.co.za>


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

2.5 is done with and no response to question about more recent versions.

----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Wed Jun  1 08:19:53 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:19:53 +0000
Subject: [issue9678] uuid._ifconfig_getnode can't work on NetBSD
In-Reply-To: <1282705798.9.0.0619423981288.issue9678@psf.upfronthosting.co.za>
Message-ID: <1306909193.09.0.793186002144.issue9678@psf.upfronthosting.co.za>


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

2.5 is closed and 2.6 and 3.1 are or soon will be security fix only.
I do not know if any developer works with NetBSD.

----------
nosy: +terry.reedy
versions: +Python 3.2 -Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Jun  1 08:20:34 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:20:34 +0000
Subject: [issue9812] cPickle segfault with nested dicts in threaded env
In-Reply-To: <1284044601.98.0.223579173983.issue9812@psf.upfronthosting.co.za>
Message-ID: <1306909234.65.0.856377869187.issue9812@psf.upfronthosting.co.za>


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


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Wed Jun  1 08:21:14 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:21:14 +0000
Subject: [issue9699] invalid call of Windows API _popen() generating The
	input	line is too long error message
In-Reply-To: <1282909340.45.0.225876683414.issue9699@psf.upfronthosting.co.za>
Message-ID: <1306909274.0.0.957239751221.issue9699@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Jun  1 08:21:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:21:47 +0000
Subject: [issue9972] PyGILState_XXX missing in Python builds without threads
In-Reply-To: <1285687340.14.0.296693885275.issue9972@psf.upfronthosting.co.za>
Message-ID: <1306909307.35.0.58459610788.issue9972@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Jun  1 08:22:43 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:22:43 +0000
Subject: [issue8678] crashers in rgbimg
In-Reply-To: <1273526642.93.0.89259252042.issue8678@psf.upfronthosting.co.za>
Message-ID: <1306909363.88.0.924109689678.issue8678@psf.upfronthosting.co.za>


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


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Wed Jun  1 08:23:11 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:23:11 +0000
Subject: [issue10376] ZipFile unzip is unbuffered
In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za>
Message-ID: <1306909391.69.0.269700559368.issue10376@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.2, Python 3.3 -Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Jun  1 08:24:37 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:24:37 +0000
Subject: [issue2901] "error: can't allocate region" from mmap() when receiving
	big chunk of data
In-Reply-To: <1211069816.05.0.311102248623.issue2901@psf.upfronthosting.co.za>
Message-ID: <1306909477.98.0.0171067612297.issue2901@psf.upfronthosting.co.za>


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

Never verified for current release. 2.5 closed.

----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Wed Jun  1 08:24:59 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:24:59 +0000
Subject: [issue10878] asyncore does not react properly on close()
In-Reply-To: <1294641638.26.0.753920382409.issue10878@psf.upfronthosting.co.za>
Message-ID: <1306909499.19.0.0556753973473.issue10878@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.5, Python 2.6

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

From report at bugs.python.org  Wed Jun  1 08:25:13 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:25:13 +0000
Subject: [issue11374] pkgutil.extend_path do not recognize py{c,o} file
In-Reply-To: <1299076268.23.0.272938075364.issue11374@psf.upfronthosting.co.za>
Message-ID: <1306909513.55.0.866308025274.issue11374@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Jun  1 08:25:42 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:25:42 +0000
Subject: [issue11357] Add support for PEP 381 -- Mirror Authenticity
In-Reply-To: <1298948795.56.0.864012658533.issue11357@psf.upfronthosting.co.za>
Message-ID: <1306909542.54.0.578291871133.issue11357@psf.upfronthosting.co.za>


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


----------
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/issue11357>
_______________________________________

From report at bugs.python.org  Wed Jun  1 08:26:10 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:26:10 +0000
Subject: [issue11409] pysetup --search should return non-zero when a dist is
	not installed and print a message stating the fact.
In-Reply-To: <1299349750.25.0.306966867422.issue11409@psf.upfronthosting.co.za>
Message-ID: <1306909570.2.0.606076522884.issue11409@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Jun  1 08:27:17 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:27:17 +0000
Subject: [issue11449] tarfile tries to file_.tell() even when creating a new
	archive
In-Reply-To: <1299646812.24.0.118802902773.issue11449@psf.upfronthosting.co.za>
Message-ID: <1306909637.82.0.984829536307.issue11449@psf.upfronthosting.co.za>


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

2.5 is closed; 2.6 security fix only, 3.1 soon will be

----------
nosy: +terry.reedy
versions:  -Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Jun  1 08:27:29 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:27:29 +0000
Subject: [issue11453] asyncore.file_wrapper should implement __del__ and call
	close there to prevent resource leaks and behave like
	socket.socket does.
In-Reply-To: <1299698993.48.0.0930746174281.issue11453@psf.upfronthosting.co.za>
Message-ID: <1306909649.84.0.224766458212.issue11453@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Jun  1 08:28:05 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:28:05 +0000
Subject: [issue11439] subversion keyword breakage
In-Reply-To: <1299597022.39.0.100246713924.issue11439@psf.upfronthosting.co.za>
Message-ID: <1306909685.06.0.907213211614.issue11439@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.5

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

From report at bugs.python.org  Wed Jun  1 08:29:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:29:47 +0000
Subject: [issue11419] Python-ast.[ch] out-of-date w.r.t. sources in fresh 2.5
	checkout
In-Reply-To: <1299455274.97.0.594517189551.issue11419@psf.upfronthosting.co.za>
Message-ID: <1306909787.71.0.378085859809.issue11419@psf.upfronthosting.co.za>


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


----------
status: open -> closed

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

From report at bugs.python.org  Wed Jun  1 08:30:00 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:30:00 +0000
Subject: [issue11671] Security hole in wsgiref.headers.Headers
In-Reply-To: <1301055298.41.0.957962483368.issue11671@psf.upfronthosting.co.za>
Message-ID: <1306909800.25.0.118350976267.issue11671@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.5

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

From report at bugs.python.org  Wed Jun  1 08:30:44 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:30:44 +0000
Subject: [issue11728] mbox parser incorrect behaviour
In-Reply-To: <1301573066.6.0.277247050127.issue11728@psf.upfronthosting.co.za>
Message-ID: <1306909844.65.0.568164783336.issue11728@psf.upfronthosting.co.za>


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


----------
stage:  -> test needed
type:  -> behavior
versions:  -Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Jun  1 08:31:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:31:01 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1306909861.1.0.0666465069408.issue11767@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.5, Python 2.6

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

From report at bugs.python.org  Wed Jun  1 08:31:15 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:31:15 +0000
Subject: [issue11792] asyncore module print to stdout
In-Reply-To: <1302164547.51.0.00796675638599.issue11792@psf.upfronthosting.co.za>
Message-ID: <1306909875.92.0.692899815734.issue11792@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.5, Python 3.1

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

From report at bugs.python.org  Wed Jun  1 08:31:42 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:31:42 +0000
Subject: [issue9667] NetBSD curses KEY_* constants
In-Reply-To: <1282644914.67.0.328045909398.issue9667@psf.upfronthosting.co.za>
Message-ID: <1306909902.42.0.437178322245.issue9667@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Jun  1 08:31:55 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2011 06:31:55 +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: <1306909915.66.0.64800635519.issue11934@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.5

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

From report at bugs.python.org  Wed Jun  1 09:19:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jun 2011 07:19:41 +0000
Subject: [issue12230] test_subprocess.test_pass_fds() failed on x86 Tiger 3.x
In-Reply-To: <1306882126.33.0.416500122697.issue12230@psf.upfronthosting.co.za>
Message-ID: <1306912781.24.0.242194719771.issue12230@psf.upfronthosting.co.za>


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

I ran the test more than 1000 times on Linux (using -m test -F test_io, and manually patched test_io to only run this test, see also #12231 !!!) without being able to reproduce the failure. So it may be specific to Mac OS X Tiger.

----------

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

From report at bugs.python.org  Wed Jun  1 09:27:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jun 2011 07:27:07 +0000
Subject: [issue12230] test_subprocess.test_pass_fds() failed on x86 Tiger 3.x
In-Reply-To: <1306882126.33.0.416500122697.issue12230@psf.upfronthosting.co.za>
Message-ID: <1306913227.05.0.133402827815.issue12230@psf.upfronthosting.co.za>


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

> Could this be related to http://bugs.python.org/issue6559#msg123958?
> Or Issue10826?

These failures were specific to Solaris/OpenIndiana: they were "door files". Extract of fd_status.py:

    1.34 +        # Ignore Solaris door files
    1.35 +        if st.st_mode & 0xF000 != 0xd000:
    1.36 +            fds.append(fd)

----------

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

From report at bugs.python.org  Wed Jun  1 09:30:15 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 01 Jun 2011 07:30:15 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1306913415.13.0.571167549516.issue12226@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> Distutils doesn't validate PyPI server certificate, so this change
> doesn't prevent from MITM attacks, but at least it makes package
> submissions over wireless channels and public networks safer.

Is that so? It's been a while, but I think e.g. ettercap is a highly
automated tool for MITM attacks that isn't very hard to use.

----------
nosy: +skrah

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

From report at bugs.python.org  Wed Jun  1 10:06:05 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 01 Jun 2011 08:06:05 +0000
Subject: [issue12230] test_subprocess.test_pass_fds() failed on x86 Tiger 3.x
In-Reply-To: <1306882126.33.0.416500122697.issue12230@psf.upfronthosting.co.za>
Message-ID: <1306915565.2.0.553205823503.issue12230@psf.upfronthosting.co.za>


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

> These failures were specific to Solaris/OpenIndiana: they were "door files"

Yeah, I saw that but thought maybe the reason was similar, some library function in the child process was opening a file and not closing it properly.

> using -m test -F test_io, and manually patched test_io

Isn't this test_subprocess?

----------

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

From report at bugs.python.org  Wed Jun  1 10:13:17 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 01 Jun 2011 08:13:17 +0000
Subject: [issue12225] current tip doesn't build without mercurial installed
In-Reply-To: <1306882398.03.0.535494732639.issue12225@psf.upfronthosting.co.za>
	(Roumen Petrov's message of "Tue, 31 May 2011 22:53:18 +0000")
Message-ID: <87y61motpp.fsf@muni.brainbot.com>


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

Roumen Petrov <report at bugs.python.org> writes:

> Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:
>
> Check for python executable is not complete . What about if system has
> only version 3+ installed ?

The shebang in Parser/asdl_c.py reads '#! /usr/bin/env python'.
That is what the makefile is calling. So unless you want to change the
Makefile too and start calling '@PYTHON@ Parser/asdl_c.py', I think the
check is rather complete.

----------

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

From report at bugs.python.org  Wed Jun  1 11:23:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jun 2011 09:23:07 +0000
Subject: [issue12230] test_subprocess.test_pass_fds() failed on x86 Tiger 3.x
In-Reply-To: <1306882126.33.0.416500122697.issue12230@psf.upfronthosting.co.za>
Message-ID: <1306920187.71.0.740064986992.issue12230@psf.upfronthosting.co.za>


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

The leaking file descriptor is a the read end of a pipe created in the test (the test creates 5 pipes, 10 file descriptors). On creation (in the parent process), this file descriptor has the mode : st_mode=4528. In the child process, the file descriptor has the mode : st_mode=420, which is an invalid mode. The child cannot read or write into this file: write raises an OSError(9, 'Bad file descriptor') and read raises an OSError(45, 'Operation not supported'). It looks like a kernel (Darwin) bug, fixed in Mac OS X > 10.4.

----------

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

From report at bugs.python.org  Wed Jun  1 13:06:15 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 01 Jun 2011 11:06:15 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1306926375.33.0.744842539574.issue12226@psf.upfronthosting.co.za>


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

Given that 2.6.7 is rc2 with a final release scheduled in 2 days, I don't want to apply this to 2.6 right now.  Can you guarantee this won't regress for anybody?  If so, then I'm also +0 for 2.6 after the 2.6.7 release.

----------

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

From report at bugs.python.org  Wed Jun  1 13:15:51 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jun 2011 11:15:51 +0000
Subject: [issue12231] regrtest: add -k and -K options to filter tests by
	function/file names
In-Reply-To: <1306886173.49.0.536773734975.issue12231@psf.upfronthosting.co.za>
Message-ID: <1306926951.3.0.874386246848.issue12231@psf.upfronthosting.co.za>


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

IMHO it would be better to tweak regrtest so that it understand test_file.TestClass.test_method, possibly supporting wildcards.
E.g.:
  - ./python -m test test_subprocess.POSIXProcessTestCase
  - ./python -m test test_subprocess.POSIXProcessTestCase.test_pass_fds
  - ./python -m test '*codecencoding*'
  - ./python -m test 'test_subprocess.C*'

The -x/--exclude option could be extended to support this notation too and make possible to exclude specific tests classes/methods.
Wildcards are less flexible than regex, but I think they are good enough for our use case and simpler to use.

----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> feature request
versions:  -Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Jun  1 13:19:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 01 Jun 2011 11:19:48 +0000
Subject: [issue12230] test_subprocess.test_pass_fds() failed on x86 Tiger 3.x
In-Reply-To: <1306882126.33.0.416500122697.issue12230@psf.upfronthosting.co.za>
Message-ID: <E1QRjSk-0000GP-VH@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 22457ac2c2df by Victor Stinner in branch '3.2':
Close #12230: Mac OS X Tiger (10.4) has a kernel bug: sometimes, the file
http://hg.python.org/cpython/rev/22457ac2c2df

New changeset 566c42b0e750 by Victor Stinner in branch 'default':
(Merge 3.2) Close #12230: Mac OS X Tiger (10.4) has a kernel bug: sometimes,
http://hg.python.org/cpython/rev/566c42b0e750

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Jun  1 13:25:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jun 2011 11:25:42 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <201105312226.59672.victor.stinner@haypocalc.com>
Message-ID: <201106011325.38794.victor.stinner@haypocalc.com>


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

> support_linux_version.diff: cool, it's even better than the previous patch.
> You can commit it, except if you are motived for a last change: display
> the write also version in the SkipTest message (as it is done actually).

I just added a very similar function for Mac OS X which is a decorator. 
Example: @support.requires_mac_ver(10, 5).

requires_linux_version() should also be a decorator.

----------

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

From nad at acm.org  Wed Jun  1 01:00:30 2011
From: nad at acm.org (Ned Deily)
Date: Tue, 31 May 2011 16:00:30 -0700
Subject: [issue12225] current tip doesn't build without mercurial installed
References: <1306854977.0.0.17464717036.issue12225@psf.upfronthosting.co.za>
	<E1QRX9p-0004NN-13@dinsdale.python.org>
Message-ID: <nad-CA57C7.16003031052011@news.gmane.org>

In article <E1QRX9p-0004NN-13 at dinsdale.python.org>,
 Roundup Robot <report at bugs.python.org> wrote:

> Roundup Robot <devnull at devnull> added the comment:
> 
> New changeset 435eec7b41f0 by Ralf Schmitt in branch 'default':
> disable ASDLGEN if hg won't work, or if python is not installed.
> http://hg.python.org/cpython/rev/435eec7b41f0
> 
> ----------
> nosy: +python-dev
> resolution: duplicate -> fixed

Whoever pushed this - as the OP mentioned, you need to run autoconf to 
get configure updated and push that as well.

-- 
 Ned Deily,
 nad at acm.org


From report at bugs.python.org  Wed Jun  1 15:03:24 2011
From: report at bugs.python.org (=?utf-8?q?Domen_Ko=C5=BEar?=)
Date: Wed, 01 Jun 2011 13:03:24 +0000
Subject: [issue12234] unittest2 could enable regex debugging for more
	information
In-Reply-To: <1306933404.89.0.697079292496.issue12234@psf.upfronthosting.co.za>
Message-ID: <1306933404.89.0.697079292496.issue12234@psf.upfronthosting.co.za>


New submission from Domen Ko?ar <ielectric at gmail.com>:

When using self.assertRegexpMatches, it would be useful to see where did the matching stop. Maybe using re module debugging flag?

----------
components: Library (Lib)
messages: 137432
nosy: iElectric
priority: normal
severity: normal
status: open
title: unittest2 could enable regex debugging for more information
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun  1 16:11:55 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 01 Jun 2011 14:11:55 +0000
Subject: [issue12231] regrtest: add -k and -K options to filter tests by
	function/file names
In-Reply-To: <1306886173.49.0.536773734975.issue12231@psf.upfronthosting.co.za>
Message-ID: <1306937515.69.0.0747175072707.issue12231@psf.upfronthosting.co.za>


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

+1 to what Ezio said, though I'd rather have this than not have the functionality at all :)

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

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

From report at bugs.python.org  Wed Jun  1 17:04:19 2011
From: report at bugs.python.org (Dan Stromberg)
Date: Wed, 01 Jun 2011 15:04:19 +0000
Subject: [issue11449] tarfile tries to file_.tell() even when creating a new
	archive
In-Reply-To: <1299646812.24.0.118802902773.issue11449@psf.upfronthosting.co.za>
Message-ID: <1306940659.0.0.924452670734.issue11449@psf.upfronthosting.co.za>


Dan Stromberg <strombrg at gmail.com> added the comment:

Yes, I just needed to use 'w|' instead of 'w'.

Thanks!

----------
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Wed Jun  1 17:11:12 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 01 Jun 2011 15:11:12 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306913415.13.0.571167549516.issue12226@psf.upfronthosting.co.za>
Message-ID: <BANLkTik_aFuOfuL=gWmOORi7pCmoNL1U5Q@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Wed, Jun 1, 2011 at 10:30 AM, Stefan Krah <report at bugs.python.org> wrote:
>
>> Distutils doesn't validate PyPI server certificate, so this change
>> doesn't prevent from MITM attacks, but at least it makes package
>> submissions over wireless channels and public networks safer.
>
> Is that so? It's been a while, but I think e.g. ettercap is a highly
> automated tool for MITM attacks that isn't very hard to use.

This patch won't help against properly baited ettercap, but will
prevent transit sniffing of weakly protected passwords.
--
anatoly t.

----------

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

From report at bugs.python.org  Wed Jun  1 17:14:59 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 01 Jun 2011 15:14:59 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306926375.33.0.744842539574.issue12226@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=sQ9qDPibkXJiqxEmkaTNKMKaq8w@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Wed, Jun 1, 2011 at 2:06 PM, Barry A. Warsaw <report at bugs.python.org> wrote:
>
> Barry A. Warsaw <barry at python.org> added the comment:
>
> Given that 2.6.7 is rc2 with a final release scheduled in 2 days, I don't want to apply this to 2.6 right now. ?Can you guarantee this won't regress for anybody? ?If so, then I'm also +0 for 2.6 after the 2.6.7 release.

Adding catalog-sig to CC. I can guarantee this for Windows. I'll be
near Linux box tomorrow and will try upload to PyPI from there. It
still will be more authoritative if more than one person can test
upload to PyPI with this patch on different systems.
--
anatoly t.

----------

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

From report at bugs.python.org  Wed Jun  1 17:17:48 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 01 Jun 2011 15:17:48 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <BANLkTi=sQ9qDPibkXJiqxEmkaTNKMKaq8w@mail.gmail.com>
Message-ID: <BANLkTimZ7OErL+7XJO+Gu0UHLBa=z1bY3Q@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

On Wed, Jun 1, 2011 at 11:14 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> Adding catalog-sig to CC. I can guarantee this for Windows. I'll be
> near Linux box tomorrow and will try upload to PyPI from there. It
> still will be more authoritative if more than one person can test
> upload to PyPI with this patch on different systems.

The interesting case will be for a build that doesn't include SSL support.

  -Fred

----------
nosy: +fdrake

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

From report at bugs.python.org  Wed Jun  1 17:22:53 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 01 Jun 2011 15:22:53 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <BANLkTimZ7OErL+7XJO+Gu0UHLBa=z1bY3Q@mail.gmail.com>
Message-ID: <BANLkTi=Ha-nHor3FGoiz5wRV+UsF1WKwyA@mail.gmail.com>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

On Wed, Jun 1, 2011 at 5:17 PM, Fred Drake <fdrake at acm.org> wrote:
> On Wed, Jun 1, 2011 at 11:14 AM, anatoly techtonik <techtonik at gmail.com> wrote:
>> Adding catalog-sig to CC. I can guarantee this for Windows. I'll be
>> near Linux box tomorrow and will try upload to PyPI from there. It
>> still will be more authoritative if more than one person can test
>> upload to PyPI with this patch on different systems.
>
> The interesting case will be for a build that doesn't include SSL support.

Yeah.. We do have in packaging a way to test against a PyPI server
that gets launched on a real socket, so what we could do is:

1/ add a test that tries to upload and register via ssh
2/ make sure it fallbacks to http if _ssl is not found

>
>
> ?-Fred
>
> --
> Fred L. Drake, Jr.? ? <fdrake at acm.org>
> "Give me the luxuries of life and I will willingly do without the necessities."
> ?? --Frank Lloyd Wright
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>

----------

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

From report at bugs.python.org  Wed Jun  1 17:26:37 2011
From: report at bugs.python.org (Cal Leeming)
Date: Wed, 01 Jun 2011 15:26:37 +0000
Subject: [issue12235] subprocess.check_output throws wrong exception if non
	executable
In-Reply-To: <1306941997.06.0.876478438314.issue12235@psf.upfronthosting.co.za>
Message-ID: <1306941997.06.0.876478438314.issue12235@psf.upfronthosting.co.za>


New submission from Cal Leeming <cal.leeming at simplicitymedialtd.co.uk>:

If you attempt to call subprocess.check_output() on a file which is not executable, it gives a "file not found" exception, rather than "file not executable". Took me about 3 hours to figure out why it kept saying the file didn't exist, when it clearly did :|


 ***@***# ls -la ***/src/webapp/tools/grab.sh
-rwxr-xr-x 1 *** *** 4398 Apr 19 10:55 ***/src/webapp/tools/grab.sh

 ***@***# ***/src/webapp/tools/grab.sh
bash: ***/src/webapp/tools/grab.sh: /bin/sh^M: bad interpreter: No such file or directory


Traceback (most recent call last):

  File "***/src/webapp/../webapp/idx/fourchan/tasks.py", line 77, in run
    subprocess.check_output([ DOWNLOAD_BIN, ])

  File "/usr/local/lib/python2.7/subprocess.py", line 530, in check_output
    process = Popen(stdout=PIPE, *popenargs, **kwargs)

  File "/usr/local/lib/python2.7/subprocess.py", line 672, in __init__
    errread, errwrite)

  File "/usr/local/lib/python2.7/subprocess.py", line 1201, in _execute_child
    raise child_exception

OSError: [Errno 2] No such file or directory


Request:
None

----------
messages: 137439
nosy: Cal.Leeming
priority: normal
severity: normal
status: open
title: subprocess.check_output throws wrong exception if non executable

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

From report at bugs.python.org  Wed Jun  1 17:28:01 2011
From: report at bugs.python.org (Cal Leeming)
Date: Wed, 01 Jun 2011 15:28:01 +0000
Subject: [issue12235] subprocess.check_output throws wrong exception if non
	executable
In-Reply-To: <1306941997.06.0.876478438314.issue12235@psf.upfronthosting.co.za>
Message-ID: <1306942081.09.0.758106316155.issue12235@psf.upfronthosting.co.za>


Cal Leeming <cal.leeming at simplicitymedialtd.co.uk> added the comment:

Oh also, here is the version:


 simplicitymedialtd at sws01.internal [~/webapps/cdn06.prod/src/webapp/cmd] > python
Python 2.7 Stackless 3.1b3 060516 (release27-maint, Aug 29 2010, 15:44:48)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.

----------
components: +None
type:  -> behavior
versions: +Python 2.7

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

From report at bugs.python.org  Wed Jun  1 17:41:35 2011
From: report at bugs.python.org (Jakub Wilk)
Date: Wed, 01 Jun 2011 15:41:35 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1306942895.42.0.45961715405.issue12226@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/issue12226>
_______________________________________

From report at bugs.python.org  Wed Jun  1 18:49:25 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 01 Jun 2011 16:49:25 +0000
Subject: [issue12235] subprocess.check_output throws wrong exception if non
	executable
In-Reply-To: <1306941997.06.0.876478438314.issue12235@psf.upfronthosting.co.za>
Message-ID: <1306946965.31.0.234744157636.issue12235@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Python is not raising this error, your OS is.
It doesn't find the interpreter, and if you look carefully, it's clear why:

bash: ***/src/webapp/tools/grab.sh: /bin/sh^M: bad interpreter: No such file or directory

See the ^M after /bin/sh?
It's looks like a DOS line ending, and the spurious \r character is concatenated to the intepreter path, leading to this error.
You didn't copy this script through a Windows box, didn't you?
Just run dos2unix on your script, and it should solve your problem.

----------
nosy: +charles-francois.natali

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

From report at bugs.python.org  Wed Jun  1 18:57:06 2011
From: report at bugs.python.org (Cal Leeming)
Date: Wed, 01 Jun 2011 16:57:06 +0000
Subject: [issue12235] subprocess.check_output throws wrong exception if non
	executable
In-Reply-To: <1306941997.06.0.876478438314.issue12235@psf.upfronthosting.co.za>
Message-ID: <1306947426.16.0.0804533880628.issue12235@psf.upfronthosting.co.za>


Cal Leeming <cal.leeming at simplicitymedialtd.co.uk> added the comment:

Yeah, I resolved the issue already. This bug report is focused primarily on the (somewhat misleading) exception message given back.  

I think it should at least include "bad interpreter", otherwise it is a tad misleading.

Cal

----------

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

From report at bugs.python.org  Wed Jun  1 19:19:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 01 Jun 2011 17:19:38 +0000
Subject: [issue12235] subprocess loses stderr information when _execute_child
	fails
In-Reply-To: <1306941997.06.0.876478438314.issue12235@psf.upfronthosting.co.za>
Message-ID: <1306948778.22.0.663004787239.issue12235@psf.upfronthosting.co.za>


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

Subprocess is throwing the correct exception, what it isn't doing is preserving stderr.  The stderr output in question is not coming from the *subprocess* (the process hasn't been created yet).  It would be nice if that stderr output could be added to the exception message, but that is not normally the way os errors are handled in python.

----------
nosy: +gregory.p.smith, r.david.murray
title: subprocess.check_output throws wrong exception if non executable -> subprocess loses stderr information when _execute_child fails
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun  1 19:27:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Jun 2011 17:27:28 +0000
Subject: [issue11975] Fix referencing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1306949248.97.0.584514798654.issue11975@psf.upfronthosting.co.za>


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

Jonas, I owe you an apology: when I abruptly asked ?Could you make an effort to accept? etc., I had misread your message and thought you were asking to change the roles, but you were speaking of directives, so my comment was out of line.  Sorry.

----------

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

From report at bugs.python.org  Wed Jun  1 19:34:47 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 01 Jun 2011 17:34:47 +0000
Subject: [issue12235] subprocess loses stderr information when _execute_child
	fails
In-Reply-To: <1306941997.06.0.876478438314.issue12235@psf.upfronthosting.co.za>
Message-ID: <1306949687.69.0.612170149279.issue12235@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I think it should at least include "bad interpreter", otherwise it is a tad misleading.

It just forwards the error raised by the exec system call:

$ cat foo.sh 
#! /bin/foo
$ strace ./foo.sh 
execve("./foo.sh", ["./foo.sh"], [/* 38 vars */]) = -1 ENOENT (No such file or directory)

> Subprocess is throwing the correct exception, what it isn't doing is preserving stderr.

There's not stderr, it's just execve which is failing with errno set to ENOENT.
Now, if you wonder how bash manages to print this "bad interpreter" error message, it's simple: it first checks for common errno values (ENOEXEC, ENOMEM), and then it parses the shebang: if it finds a line starting with #!, it assumes that it's a bad interpreter, and prints the offending line.
That's it.

Suggesting to close as invalid.

----------

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

From report at bugs.python.org  Wed Jun  1 19:34:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jun 2011 17:34:58 +0000
Subject: [issue11975] Fix referencing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1306949698.48.0.870989443504.issue11975@psf.upfronthosting.co.za>


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

FWIW using the class directive also adds a 'class' before the name, and I -1 about having int()/float()/etc. prepended by 'class' in the functions.rst page.
What happens if we leave ".. function::" there and use ".. class::" in another page where all the methods are actually documented?

----------

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

From report at bugs.python.org  Wed Jun  1 19:37:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Jun 2011 17:37:52 +0000
Subject: [issue11975] Fix referencing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1306949872.73.0.907797957773.issue11975@psf.upfronthosting.co.za>


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

Agreed.

I experimented with tuple and tuple.count and it turns out that it?s not easily solved: the count method is documented in the table describing all sequences methods, which should not be duplicated IMO; I tried adding a .. method:: tuple.append directive to create a link target, but that does not work in a table row.  Maybe the index directives can do what we want, but I do not understand them.

----------

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

From report at bugs.python.org  Wed Jun  1 19:38:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Jun 2011 17:38:55 +0000
Subject: [issue12200] bdist_wininst install_script not run on uninstall
In-Reply-To: <1306548527.55.0.138367912737.issue12200@psf.upfronthosting.co.za>
Message-ID: <1306949935.69.0.268109588644.issue12200@psf.upfronthosting.co.za>


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

I cannot review the patch (I don?t know C), but I will trust you.  Could you add a test to prevent regressions?

----------
versions:  -Python 3.4

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

From report at bugs.python.org  Wed Jun  1 19:49:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Jun 2011 17:49:16 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306950556.92.0.978348180069.issue11416@psf.upfronthosting.co.za>


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

Looks good, thanks.

----------

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

From report at bugs.python.org  Wed Jun  1 19:54:28 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 01 Jun 2011 17:54:28 +0000
Subject: [issue12235] subprocess throws wrong exception if script can't be
	executed
In-Reply-To: <1306941997.06.0.876478438314.issue12235@psf.upfronthosting.co.za>
Message-ID: <1306950868.22.0.0170777356662.issue12235@psf.upfronthosting.co.za>


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

Ah, I see.  Agreed with the closing, then.

Cal: one way to debug this kind of thing is to try the same command with shell=True.  Then the shell will generate its special error message.

Changing the title back to something that might be recognizable to others who run into this problem.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
title: subprocess loses stderr information when _execute_child fails -> subprocess throws wrong exception if script can't be executed

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

From report at bugs.python.org  Wed Jun  1 19:57:00 2011
From: report at bugs.python.org (Cal Leeming)
Date: Wed, 01 Jun 2011 17:57:00 +0000
Subject: [issue12235] subprocess throws wrong exception if script can't be
	executed
In-Reply-To: <1306941997.06.0.876478438314.issue12235@psf.upfronthosting.co.za>
Message-ID: <1306951020.01.0.98711745737.issue12235@psf.upfronthosting.co.za>


Cal Leeming <cal.leeming at simplicitymedialtd.co.uk> added the comment:

Ah okay, shell=True is a good work around then :)

Thanks!

Cal

----------

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

From report at bugs.python.org  Wed Jun  1 20:04:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Jun 2011 18:04:23 +0000
Subject: [issue12170] Bytes.index() and bytes.count() should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1306951463.26.0.332924427031.issue12170@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/issue12170>
_______________________________________

From report at bugs.python.org  Wed Jun  1 20:05:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Jun 2011 18:05:00 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1306951500.29.0.926180314341.issue12191@psf.upfronthosting.co.za>


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

> I was just asking given the "unusual" situation 2.7 is (i.e. a very
> long support series)
Support means bug fixes.  Long-term means that the bugfix period (before going into security mode) is extended, not that it can get new features: that?s exclusively for 3.3.

> rewrap: I kinda find that almost every core dev has his opinion on this :)
Heh :)

----------

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

From report at bugs.python.org  Wed Jun  1 20:17:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Jun 2011 18:17:25 +0000
Subject: [issue11374] pkgutil.extend_path do not recognize py{c,o} file
In-Reply-To: <1299076268.23.0.272938075364.issue11374@psf.upfronthosting.co.za>
Message-ID: <1306952245.46.0.456836474182.issue11374@psf.upfronthosting.co.za>


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

Hi, thanks for the report and patch.  I think the code should not find byte-compiled files if sys.dont_write_bytecode is true, and it should not find pyo files when sys.flags.optimize has a certain value (I don?t remember if it?s 1 or 2).  It also requires tests.

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

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

From report at bugs.python.org  Wed Jun  1 20:31:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 01 Jun 2011 18:31:20 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <E1QRqCN-0003sl-FJ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 4124d1f75b93 by Charles-Fran?ois Natali in branch 'default':
Issue #12196: Add a note on os.pipe2() in the "Whats' new in Python 3.3"
http://hg.python.org/cpython/rev/4124d1f75b93

----------

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

From report at bugs.python.org  Wed Jun  1 20:55:57 2011
From: report at bugs.python.org (Julian Taylor)
Date: Wed, 01 Jun 2011 18:55:57 +0000
Subject: [issue12236] Tkinter __version__ uses subversion substitution
In-Reply-To: <1306954557.42.0.779197130773.issue12236@psf.upfronthosting.co.za>
Message-ID: <1306954557.42.0.779197130773.issue12236@psf.upfronthosting.co.za>


New submission from Julian Taylor <jtaylor.debian at googlemail.com>:

./Lib/lib-tk/Tkinter.py:33 has this svn keyword substitution:
 __version__ = "$Revision$"

Due to the change to hg this field is not substituted and makes __version__ quite pointless.
This affects the python 2.7.2rc1.

----------
components: Tkinter
messages: 137455
nosy: jtaylor
priority: normal
severity: normal
status: open
title: Tkinter __version__ uses subversion substitution
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun  1 21:20:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 01 Jun 2011 19:20:35 +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: <1306956035.92.0.755154486151.issue11934@psf.upfronthosting.co.za>


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

Well, IIUC the Setup lines indicate where to find the system version of the libraries (otherwise the included zlib is used).  So I'm not at all sure that there is a bug here.  If you change Setup, you need to change it correctly for your intended installation.

----------
nosy: +r.david.murray
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Wed Jun  1 22:23:48 2011
From: report at bugs.python.org (Aldona Majorek)
Date: Wed, 01 Jun 2011 20:23:48 +0000
Subject: [issue11453] asyncore.file_wrapper should implement __del__ and call
	close there to prevent resource leaks and behave like
	socket.socket does.
In-Reply-To: <1299698993.48.0.0930746174281.issue11453@psf.upfronthosting.co.za>
Message-ID: <1306959828.54.0.454799757127.issue11453@psf.upfronthosting.co.za>


Aldona Majorek <amajorek at google.com> added the comment:

Adding __exit__ will not make asyncore.file_wrapper close file descriptor when garbage collected.

Here is clone of socket.py solution for the same problem.

  def close(self):
    if self.fd:
      os.close(self.fd)
      self.fd = None # or maybe self.fd = 0 will be better

  def __del__(self):
    try:
      self.close()
    except:
      # close() may fail if __init__ didn't complete
      pass

----------

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

From report at bugs.python.org  Wed Jun  1 22:42:24 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 01 Jun 2011 20:42:24 +0000
Subject: [issue3014] file_dealloc() assumes errno is set when EOF is returned
In-Reply-To: <1212184451.2.0.27521352304.issue3014@psf.upfronthosting.co.za>
Message-ID: <1306960944.34.0.308349027183.issue3014@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


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

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

From report at bugs.python.org  Wed Jun  1 22:44:04 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 01 Jun 2011 20:44:04 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1306961044.97.0.0594094081035.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I have this working when you stat the symlink from the directory it was created or above...but oddly it does not work when you open a symlink below the directory it exists in.

DeviceIoControl isn't used for reparse tag handling anymore, and I'm using GetFinalPathNameByHandle similar to how it was used in previous versions of this code. There's still a case to handle and maybe some cleanup, but there's decent progress and hope that I can get it done very soon.

----------

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

From report at bugs.python.org  Wed Jun  1 22:48:41 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 01 Jun 2011 20:48:41 +0000
Subject: [issue5043] get_msvcr() returns None rather than []
In-Reply-To: <1232819450.01.0.0863165056727.issue5043@psf.upfronthosting.co.za>
Message-ID: <1306961321.89.0.415545366491.issue5043@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


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

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

From report at bugs.python.org  Wed Jun  1 23:10:59 2011
From: report at bugs.python.org (Jonas H.)
Date: Wed, 01 Jun 2011 21:10:59 +0000
Subject: [issue11975] Fix referencing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1306962659.5.0.852955220902.issue11975@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

> Jonas, I owe you an apology [...]

Thanks ?ric, I got a bit worried about getting on your nerves...

Based on Ezio's idea: What happens if we have both a ".. function:: foo" and ".. class:: foo" -- where do :func:`foo` and :class:`foo` link to (internally and using intersphinx)?

----------

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

From report at bugs.python.org  Wed Jun  1 23:14:37 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 01 Jun 2011 21:14:37 +0000
Subject: [issue12236] Tkinter __version__ uses subversion substitution
In-Reply-To: <1306954557.42.0.779197130773.issue12236@psf.upfronthosting.co.za>
Message-ID: <1306962877.0.0.47964673928.issue12236@psf.upfronthosting.co.za>


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


----------
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Jun  1 23:22:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Jun 2011 21:22:34 +0000
Subject: [issue11975] Fix referencing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1306963354.43.0.523215539016.issue11975@psf.upfronthosting.co.za>


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

I think the only way to find it out is to try it and see.
In the worst case, sphinx will give an error while building the doc, if we are lucky it will just pick one of the two (or even better the one defined with the function directive while using :func:`` and the other one while using :class:``).
You can also experiment with :noindex: but I'm not sure it will do anything useful here.

----------

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

From report at bugs.python.org  Wed Jun  1 23:31:55 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 01 Jun 2011 21:31:55 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <201106011325.38794.victor.stinner@haypocalc.com>
Message-ID: <BANLkTingDOOap4fXHzWAf+CM9EAza0zyFA@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

> requires_linux_version() should also be a decorator.

Patch attached.

----------
Added file: http://bugs.python.org/file22219/support_linux_version.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________
-------------- next part --------------
diff -r 22f077f82e74 Lib/test/support.py
--- a/Lib/test/support.py	Wed Jun 01 20:44:40 2011 +0200
+++ b/Lib/test/support.py	Wed Jun 01 23:26:57 2011 +0200
@@ -37,8 +37,8 @@
     "Error", "TestFailed", "ResourceDenied", "import_module",
     "verbose", "use_resources", "max_memuse", "record_original_stdout",
     "get_original_stdout", "unload", "unlink", "rmtree", "forget",
-    "is_resource_enabled", "requires", "linux_version", "requires_mac_ver",
-    "find_unused_port", "bind_port",
+    "is_resource_enabled", "requires", "requires_linux_version",
+    "requires_mac_ver", "find_unused_port", "bind_port",
     "IPV6_ENABLED", "is_jython", "TESTFN", "HOST", "SAVEDCWD", "temp_cwd",
     "findfile", "sortdict", "check_syntax_error", "open_urlresource",
     "check_warnings", "CleanImport", "EnvironmentVarGuard", "TransientResource",
@@ -292,13 +292,32 @@
             msg = "Use of the `%s' resource not enabled" % resource
         raise ResourceDenied(msg)
 
-def linux_version():
-    try:
-        # platform.release() is something like '2.6.33.7-desktop-2mnb'
-        version_string = platform.release().split('-')[0]
-        return tuple(map(int, version_string.split('.')))
-    except ValueError:
-        return 0, 0, 0
+def requires_linux_version(*min_version):
+    """Decorator raising SkipTest if the OS is Linux and the kernel version is
+    less than min_version.
+
+    For example, @requires_linux_version(2, 6, 35) raises SkipTest if the Linux
+    kernel version is less than 2.6.35.
+    """
+    def decorator(func):
+        @functools.wraps(func)
+        def wrapper(*args, **kw):
+            if sys.platform.startswith('linux'):
+                version_txt = platform.release().split('-', 1)[0]
+                try:
+                    version = tuple(map(int, version_txt.split('.')))
+                except ValueError:
+                    pass
+                else:
+                    if version < min_version:
+                        min_version_txt = '.'.join(map(str, min_version))
+                        raise unittest.SkipTest(
+                            "Linux kernel %s or higher required, not %s"
+                            % (min_version_txt, version_txt))
+            return func(*args, **kw)
+        wrapper.min_version = min_version
+        return wrapper
+    return decorator
 
 def requires_mac_ver(*min_version):
     """Decorator raising SkipTest if the OS is Mac OS X and the OS X
diff -r 22f077f82e74 Lib/test/test_posix.py
--- a/Lib/test/test_posix.py	Wed Jun 01 20:44:40 2011 +0200
+++ b/Lib/test/test_posix.py	Wed Jun 01 23:26:57 2011 +0200
@@ -309,11 +309,8 @@
                 fp2.close()
 
     @unittest.skipUnless(hasattr(os, 'O_CLOEXEC'), "needs os.O_CLOEXEC")
+    @support.requires_linux_version(2, 6, 23)
     def test_oscloexec(self):
-        version = support.linux_version()
-        if sys.platform == 'linux2' and version < (2, 6, 23):
-            self.skipTest("Linux kernel 2.6.23 or higher required, "
-                          "not %s.%s.%s" % version)
         fd = os.open(support.TESTFN, os.O_RDONLY|os.O_CLOEXEC)
         self.addCleanup(os.close, fd)
         self.assertTrue(fcntl.fcntl(fd, fcntl.F_GETFD) & fcntl.FD_CLOEXEC)
@@ -479,11 +476,8 @@
             os.close(writer)
 
     @unittest.skipUnless(hasattr(os, 'pipe2'), "test needs os.pipe2()")
+    @support.requires_linux_version(2, 6, 27)
     def test_pipe2(self):
-        version = support.linux_version()
-        if sys.platform == 'linux2' and version < (2, 6, 27):
-            self.skipTest("Linux kernel 2.6.27 or higher required, "
-                          "not %s.%s.%s" % version)
         self.assertRaises(TypeError, os.pipe2, 'DEADBEEF')
         self.assertRaises(TypeError, os.pipe2, 0, 0)
 
diff -r 22f077f82e74 Lib/test/test_socket.py
--- a/Lib/test/test_socket.py	Wed Jun 01 20:44:40 2011 +0200
+++ b/Lib/test/test_socket.py	Wed Jun 01 23:26:57 2011 +0200
@@ -1023,11 +1023,8 @@
         pass
 
     if hasattr(socket, "SOCK_NONBLOCK"):
+        @support.requires_linux_version(2, 6, 28)
         def testInitNonBlocking(self):
-            v = support.linux_version()
-            if v < (2, 6, 28):
-                self.skipTest("Linux kernel 2.6.28 or higher required, not %s"
-                              % ".".join(map(str, v)))
             # reinit server socket
             self.serv.close()
             self.serv = socket.socket(socket.AF_INET, socket.SOCK_STREAM |
@@ -2001,11 +1998,8 @@
                      "SOCK_CLOEXEC not defined")
 @unittest.skipUnless(fcntl, "module fcntl not available")
 class CloexecConstantTest(unittest.TestCase):
+    @support.requires_linux_version(2, 6, 28)
     def test_SOCK_CLOEXEC(self):
-        v = support.linux_version()
-        if v < (2, 6, 28):
-            self.skipTest("Linux kernel 2.6.28 or higher required, not %s"
-                          % ".".join(map(str, v)))
         with socket.socket(socket.AF_INET,
                            socket.SOCK_STREAM | socket.SOCK_CLOEXEC) as s:
             self.assertTrue(s.type & socket.SOCK_CLOEXEC)
@@ -2023,11 +2017,8 @@
             self.assertFalse(s.type & socket.SOCK_NONBLOCK)
             self.assertEqual(s.gettimeout(), None)
 
+    @support.requires_linux_version(2, 6, 28)
     def test_SOCK_NONBLOCK(self):
-        v = support.linux_version()
-        if v < (2, 6, 28):
-            self.skipTest("Linux kernel 2.6.28 or higher required, not %s"
-                          % ".".join(map(str, v)))
         # a lot of it seems silly and redundant, but I wanted to test that
         # changing back and forth worked ok
         with socket.socket(socket.AF_INET,

From report at bugs.python.org  Thu Jun  2 00:05:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jun 2011 22:05:47 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306965947.43.0.620937130327.issue12196@psf.upfronthosting.co.za>


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

Your last support_linux_version.diff patch looks good. If you are motivated, this new function can also be added to test.support of Python 3.2 (test_socket.py has the original linux_version() function).

----------

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

From report at bugs.python.org  Thu Jun  2 01:07:33 2011
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 01 Jun 2011 23:07:33 +0000
Subject: [issue12200] bdist_wininst install_script not run on uninstall
In-Reply-To: <1306548527.55.0.138367912737.issue12200@psf.upfronthosting.co.za>
Message-ID: <1306969653.39.0.0644779669874.issue12200@psf.upfronthosting.co.za>


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

Adding tests would be fairly painful - there is no test infrastructure in place for generating and running installers at all, and worse, the changes are likely to not work correctly when run from a Python "build" tree when the built DLL is not installed into System32 (the patch basically assumes an "installed" dir structure rather than a "built" one.)

----------

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

From report at bugs.python.org  Thu Jun  2 01:14:00 2011
From: report at bugs.python.org (Fabio Zadrozny)
Date: Wed, 01 Jun 2011 23:14:00 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1306970040.62.0.629818433311.issue11798@psf.upfronthosting.co.za>


Fabio Zadrozny <fabioz at users.sourceforge.net> added the comment:

Sure, will try to get a patch for next week...

----------

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

From report at bugs.python.org  Thu Jun  2 01:32:07 2011
From: report at bugs.python.org (Federico Schwindt)
Date: Wed, 01 Jun 2011 23:32:07 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1306971127.79.0.766082588334.issue12181@psf.upfronthosting.co.za>


Federico Schwindt <federico.schwindt at gmail.com> added the comment:

Adding to this, the kqueue code (and test) heavily depends on the size of these members. kqueue_event_richcompare() uses a Py_intptr_t to store the result of substracting T_UINTs which is obviusly wrong on platforms where Py_intptr and T_UINTs are not the same (which is neither related to this bug nor OpenBSD specific), the test uses sys.maxint, etc.

It'd be nice if someone cleans the code to fix all these problems and adds some more tests to cover all the members in tp_richcompare.

----------
nosy: +Federico.Schwindt

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

From report at bugs.python.org  Thu Jun  2 01:49:52 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 01 Jun 2011 23:49:52 +0000
Subject: [issue12236] Tkinter __version__ uses subversion substitution
In-Reply-To: <1306954557.42.0.779197130773.issue12236@psf.upfronthosting.co.za>
Message-ID: <1306972192.54.0.911274876903.issue12236@psf.upfronthosting.co.za>


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

Yes, it's harmless, though. I've removed it for 3.3.

----------
priority: release blocker -> normal
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Thu Jun  2 01:51:34 2011
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 01 Jun 2011 23:51:34 +0000
Subject: [issue12200] bdist_wininst install_script not run on uninstall
In-Reply-To: <1306548527.55.0.138367912737.issue12200@psf.upfronthosting.co.za>
Message-ID: <1306972294.45.0.312549748042.issue12200@psf.upfronthosting.co.za>


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

(OTOH though, I could tweak the patch to work in a built tree - it would mean appending "PCBuild" to the dir and retrying the DLL load if the other options fail...)

----------

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

From report at bugs.python.org  Thu Jun  2 03:13:10 2011
From: report at bugs.python.org (John O'Connor)
Date: Thu, 02 Jun 2011 01:13:10 +0000
Subject: [issue9858] Python and C implementations of io are out of sync
In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za>
Message-ID: <1306977190.08.0.713005207345.issue9858@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
nosy: +jcon

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

From report at bugs.python.org  Thu Jun  2 08:55:54 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 02 Jun 2011 06:55:54 +0000
Subject: [issue12236] Tkinter __version__ uses subversion substitution
In-Reply-To: <1306954557.42.0.779197130773.issue12236@psf.upfronthosting.co.za>
Message-ID: <1306997754.33.0.996193668065.issue12236@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Can we be sure it's harmless?  A quick Google search turned up at least one package that depends on Tkinter.__version__ (granted, for Python 2).

http://permalink.gmane.org/gmane.comp.python.matplotlib.general/24453

----------
nosy: +ned.deily

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

From report at bugs.python.org  Thu Jun  2 11:14:02 2011
From: report at bugs.python.org (de)
Date: Thu, 02 Jun 2011 09:14:02 +0000
Subject: [issue12237] how to open non defult browser?
In-Reply-To: <1307006042.24.0.905858439151.issue12237@psf.upfronthosting.co.za>
Message-ID: <1307006042.24.0.905858439151.issue12237@psf.upfronthosting.co.za>


New submission from de <elydana at gmail.com>:

hi all,
I'm using win7, with Ff as default browser.
i wont to open url in other browser installed on my PC.
i tried:
url = 'http://www.google.com'
op = webbrowser.get('opera')
op.open(url)

and i get this error:
Traceback (most recent call last):
  File "<pyshell#26>", line 1, in <module>
    op = webbrowser.get('opera')
  File "C:\Python27\lib\webbrowser.py", line 52, in get
    raise Error("could not locate runnable browser")
Error: could not locate runnable browser

can anyone help?

----------
messages: 137469
nosy: hirsh
priority: normal
severity: normal
status: open
title: how to open non defult browser?

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

From report at bugs.python.org  Thu Jun  2 12:03:12 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 02 Jun 2011 10:03:12 +0000
Subject: [issue1495802] cygwin: popen3 lock up
Message-ID: <1307008992.48.0.960970290829.issue1495802@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

It's not a bug.
so.readlines reads the subprocess' stdout until EOF is encountered, but in the meantime, if it writes a lot to stderr, the corresponding pipe fills up, and the subprocess blocks on the write.
You should use Popen's communicate method.

Closing as invalid.

----------
nosy: +charles-francois.natali
resolution:  -> invalid
stage: test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Jun  2 12:07:49 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 02 Jun 2011 10:07:49 +0000
Subject: [issue5384] mmap and exception type
In-Reply-To: <1235755397.37.0.107266248804.issue5384@psf.upfronthosting.co.za>
Message-ID: <1307009269.38.0.792661227846.issue5384@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a patch.

----------
keywords: +needs review, patch
nosy: +charles-francois.natali, haypo
stage:  -> patch review
versions: +Python 3.3 -Python 2.7, Python 3.1
Added file: http://bugs.python.org/file22220/mmap_exceptions.diff

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

From report at bugs.python.org  Thu Jun  2 13:13:05 2011
From: report at bugs.python.org (=?utf-8?q?Jan_Pape=C5=BE?=)
Date: Thu, 02 Jun 2011 11:13:05 +0000
Subject: [issue8050] smtplib SMTP.sendmail (TypeError: expected string or
	buffer)
In-Reply-To: <1267628417.9.0.660961800232.issue8050@psf.upfronthosting.co.za>
Message-ID: <1307013185.59.0.454524724665.issue8050@psf.upfronthosting.co.za>


Jan Pape? <honyczek at centrum.cz> added the comment:

Did you try to use this?
q = quotedata(msg.as_string())

----------
nosy: +honyczek

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

From report at bugs.python.org  Thu Jun  2 13:57:40 2011
From: report at bugs.python.org (Niels Heinen)
Date: Thu, 02 Jun 2011 11:57:40 +0000
Subject: [issue12238] Readline module loading in interactive mode
In-Reply-To: <1307015860.03.0.129842780518.issue12238@psf.upfronthosting.co.za>
Message-ID: <1307015860.03.0.129842780518.issue12238@psf.upfronthosting.co.za>


New submission from Niels Heinen <niels at heinen.ws>:

Running the python binary without a script or using the -i flag will
start the process in interactive mode. The interactive mode requires an
external module to be loaded: readline.

Per default behavior, Python also tries to load this module from the current working directory (see also trace below)

strcpy(0x7fff17609ed8, ".so")                  = 0x7fff17609ed8
fopen64("readline.so", "rb" <unfinished ...>
SYS_open("readline.so", 0, 0666)               = -2
<... fopen64 resumed> )                        = 0
strcpy(0x7fff17609ed8, "module.so")            = 0x7fff17609ed8
fopen64("readlinemodule.so", "rb" <unfinished ...>
SYS_open("readlinemodule.so", 0, 0666)

The module is imported in Modules/main.c line 663:

  if ((Py_InspectFlag || ......
    isatty(fileno(stdin))) {
      PyObject *v;
      v = PyImport_ImportModule("readline");


Why consider this a security bug: basically because you don't expect a
program to import a shared library from your current directory _unless_
you explicitly tell it to (e.g. import blah).

On a multi user system, someone could plant a malicious shared libraries
named "readline.so" in an attempt to hack a user that runs python in
interactive mode.

The risk obviously _very_ low but nevertheless worth to consider improving by, for example, loading readline with a more strict path? (e.g.  python lib directories only?)

Niels



AN EXAMPLE:
-----------
The code below is compiled to readline.so and stored in /tmp:

  void __attribute__ ((constructor)) _load();
  void _load() {
      printf("DING DONG!\n");

  }

foo at foo:/tmp$ ls -l /tmp/readline.so 
-rwxr-x--- 1 nnnnn nnn 7952 Mar 29 16:24 /tmp/readline.so
foo at foo:/tmp$ 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.
DING DONG!
>>>

----------
messages: 137473
nosy: Niels.Heinen
priority: normal
severity: normal
status: open
title: Readline module loading in interactive mode
type: security
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun  2 14:38:20 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Jun 2011 12:38:20 +0000
Subject: [issue12238] Readline module loading in interactive mode
In-Reply-To: <1307015860.03.0.129842780518.issue12238@psf.upfronthosting.co.za>
Message-ID: <1307018300.62.0.394694924722.issue12238@psf.upfronthosting.co.za>


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

This is a general principle of how Python runs in interactive mode and is not confined to loading readline.  The same would be true for any module loaded during startup, and there are quite a few that are so loaded.  Since loading modules from the current working directory is an important feature of using python in interactive mode, this is not something that is likely to be changed.

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

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

From report at bugs.python.org  Thu Jun  2 14:54:22 2011
From: report at bugs.python.org (Julian Taylor)
Date: Thu, 02 Jun 2011 12:54:22 +0000
Subject: [issue12236] Tkinter __version__ uses subversion substitution
In-Reply-To: <1306954557.42.0.779197130773.issue12236@psf.upfronthosting.co.za>
Message-ID: <1307019262.99.0.309930999648.issue12236@psf.upfronthosting.co.za>


Julian Taylor <jtaylor.debian at googlemail.com> added the comment:

matplotlib fails to build due to this with 2.7.2rc1 in ubuntu oneiric (but its seems simple to fix):
https://launchpad.net/ubuntu/+source/matplotlib/1.0.1-2ubuntu1/+build/2535369

----------

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

From report at bugs.python.org  Thu Jun  2 14:55:54 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 02 Jun 2011 12:55:54 +0000
Subject: [issue12236] Tkinter __version__ uses subversion substitution
In-Reply-To: <1306997754.33.0.996193668065.issue12236@psf.upfronthosting.co.za>
Message-ID: <BANLkTimaV4ZYB9bYqQONVUL9Uvbi9gfx-g@mail.gmail.com>


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

2011/6/2 Ned Deily <report at bugs.python.org>:
>
> Ned Deily <nad at acm.org> added the comment:
>
> Can we be sure it's harmless? ?A quick Google search turned up at least one package that depends on Tkinter.__version__ (granted, for Python 2).
>
> http://permalink.gmane.org/gmane.comp.python.matplotlib.general/24453

I suppose we replace it with some old Subversion number.

----------

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

From report at bugs.python.org  Thu Jun  2 16:13:44 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Thu, 02 Jun 2011 14:13:44 +0000
Subject: [issue12239] msilib VT_EMPTY SummaryInformation properties raise an
	error (suggest returning None)
In-Reply-To: <1307024024.44.0.716968870376.issue12239@psf.upfronthosting.co.za>
Message-ID: <1307024024.44.0.716968870376.issue12239@psf.upfronthosting.co.za>


New submission from Mark Mc Mahon <mtnbikingmark at gmail.com>:

Using "some.msi" where the first property is VT_EMPTY

Using COM:
>>> from win32com.client import gencache
>>> com_lib = gencache.EnsureModule('{000C1092-0000-0000-C000-000000000046}', 409, 1, 0)
>>> com_msi = com_lib.Installer()
>>> db = com_msi.OpenDatabase('some.msi', 0)
>>> si = db.GetSummaryInformation(0)
>>> repr(si.Property(0))
'None'

Using msilib:
>>> import msilib
>>> db = msilib.OpenDatabase(r'some.msi', 0)
>>> si = db.GetSummaryInformation(0)
>>> si.GetProperty(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NotImplementedError: result of type 0

I aim to submit a patch that so that SummaryInformation.GetProperty() with a type of VT_EMPTY will return None.

----------
components: Windows
messages: 137478
nosy: markm
priority: normal
severity: normal
status: open
title: msilib VT_EMPTY SummaryInformation properties raise an error (suggest returning None)
versions: Python 3.2

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

From report at bugs.python.org  Thu Jun  2 16:14:08 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 02 Jun 2011 14:14:08 +0000
Subject: [issue12239] msilib VT_EMPTY SummaryInformation properties raise an
	error (suggest returning None)
In-Reply-To: <1307024024.44.0.716968870376.issue12239@psf.upfronthosting.co.za>
Message-ID: <1307024048.27.0.0749616884842.issue12239@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/issue12239>
_______________________________________

From report at bugs.python.org  Thu Jun  2 16:14:49 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 02 Jun 2011 14:14:49 +0000
Subject: [issue12239] msilib VT_EMPTY SummaryInformation properties raise an
	error (suggest returning None)
In-Reply-To: <1307024024.44.0.716968870376.issue12239@psf.upfronthosting.co.za>
Message-ID: <1307024089.54.0.799623058913.issue12239@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Jun  2 16:59:39 2011
From: report at bugs.python.org (Erik Bray)
Date: Thu, 02 Jun 2011 14:59:39 +0000
Subject: [issue12240] Allow multiple setup_hooks
In-Reply-To: <1307026779.27.0.653754848212.issue12240@psf.upfronthosting.co.za>
Message-ID: <1307026779.27.0.653754848212.issue12240@psf.upfronthosting.co.za>


New submission from Erik Bray <erik.m.bray at gmail.com>:

I have a use case where I have a small library of setup_hook functions for various purposes that are used by multiple projects.  Some projects may want to use more than one of these setup_hooks.

I can certainly create a wrapper hook for each function that calls all the necessary hooks.  But that gets a little tedious and seems unnecessary.  In this use case it would be fine if I could just list a set of setup_hooks to be executed in sequence.

It is, of course, up the developer to be sure that none of these setup_hooks have conflicting actions.

As a temporary workaround I wrote a setup_hook called chain_setup_hooks.  I then looks for an option called "setup_hooks" which behaves as I've described.  This works fine, though I don't see why setup_hook shouldn't allow multiple values to begin with.

----------
assignee: tarek
components: Distutils2
messages: 137479
nosy: alexis, eric.araujo, erik.bray, tarek
priority: normal
severity: normal
status: open
title: Allow multiple setup_hooks
type: feature request

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

From report at bugs.python.org  Thu Jun  2 17:25:14 2011
From: report at bugs.python.org (Tim Koopman)
Date: Thu, 02 Jun 2011 15:25:14 +0000
Subject: [issue12241] email.header.Header encoding fails on empty header
In-Reply-To: <1307028314.79.0.859095515398.issue12241@psf.upfronthosting.co.za>
Message-ID: <1307028314.79.0.859095515398.issue12241@psf.upfronthosting.co.za>


New submission from Tim Koopman <python.org at nandoe.net>:

Creating an empty header produces an exception when calling the encode function:

>>> from email.header import Header
>>> Header('', 'iso-8859-1').encode()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/email/header.py", line 317, in encode
    formatter.feed(lines[0], charset)
IndexError: list index out of range

According to RFC822, empty headers are valid (and are found in the wild anyway), so this should just work.

I've attached a trivial fix that appears to work.

----------
components: Library (Lib)
files: header.patch
keywords: patch
messages: 137480
nosy: ntkoopman
priority: normal
severity: normal
status: open
title: email.header.Header encoding fails on empty header
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22221/header.patch

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

From report at bugs.python.org  Thu Jun  2 17:28:43 2011
From: report at bugs.python.org (Eli Collins)
Date: Thu, 02 Jun 2011 15:28:43 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>


New submission from Eli Collins <elic at assurancetechnologies.com>:

It would be useful to have an environment marker which matched the compiler being used when compiling a C extension. 

Sometimes different compilers require different options (different lib names, different flags, etc); distutils1 setup.py files which have to deal with this currently go through some convolutions to determine the current compiler, and then dynamically modify extra_compile_args before handing them off to setup. 

Since packaging is moving to a setup.cfg file, it would be useful to be able to use an environment marker along the lines of  'extra_compile_args = -Dmingw_specific_flag ; packaging.c_compiler == "mingw"', allowing for special options for mingw vs msvc, etc. 

Since issue 11921 made it sound like environment markers had been expanded to the extensions sections, I'm hoping this isn't too complicated (but don't know the codebase well enough to write a patch myself).

----------
assignee: tarek
components: Distutils2
messages: 137481
nosy: alexis, eli.collins, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils2 environment marker for current compiler
type: feature request

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

From report at bugs.python.org  Thu Jun  2 17:38:18 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 02 Jun 2011 15:38:18 +0000
Subject: [issue12238] Readline module loading in interactive mode
In-Reply-To: <1307015860.03.0.129842780518.issue12238@psf.upfronthosting.co.za>
Message-ID: <1307029098.31.0.695263115023.issue12238@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/issue12238>
_______________________________________

From report at bugs.python.org  Thu Jun  2 17:46:24 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Jun 2011 15:46:24 +0000
Subject: [issue12241] email.header.Header encoding fails on empty header
In-Reply-To: <1307028314.79.0.859095515398.issue12241@psf.upfronthosting.co.za>
Message-ID: <1307029584.01.0.728152426227.issue12241@psf.upfronthosting.co.za>


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

I can't reproduce this.  What exact version of Python are you using?

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

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

From report at bugs.python.org  Thu Jun  2 17:48:24 2011
From: report at bugs.python.org (Bryce Verdier)
Date: Thu, 02 Jun 2011 15:48:24 +0000
Subject: [issue12243] getpass.getuser works on OSX
In-Reply-To: <1307029704.02.0.858553376312.issue12243@psf.upfronthosting.co.za>
Message-ID: <1307029704.02.0.858553376312.issue12243@psf.upfronthosting.co.za>


New submission from Bryce Verdier <bryceverdier at gmail.com>:

In the docs for getpass:
http://docs.python.org/release/2.6.6/library/getpass.html (as an example).

It hints that getuser() doesn't work on OSX. I tried this out and it works fine for python 2.6 on 10.6.

I have included a patch for this. I believe the cleanest way to handle this is to remove the "Availability" entry as it's no longer necessary.

----------
assignee: docs at python
components: Documentation
files: getuser.patch
keywords: patch
messages: 137483
nosy: docs at python, louiscipher
priority: normal
severity: normal
status: open
title: getpass.getuser works on OSX
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file22222/getuser.patch

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

From report at bugs.python.org  Thu Jun  2 18:18:19 2011
From: report at bugs.python.org (Tim Koopman)
Date: Thu, 02 Jun 2011 16:18:19 +0000
Subject: [issue12241] email.header.Header encoding fails on empty header
In-Reply-To: <1307028314.79.0.859095515398.issue12241@psf.upfronthosting.co.za>
Message-ID: <1307031499.38.0.815389859473.issue12241@psf.upfronthosting.co.za>


Tim Koopman <python.org at nandoe.net> added the comment:

The default Arch Linux version: 3.2.0

Python 3.2 (r32:88445, Apr 15 2011, 11:09:05)

----------

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

From report at bugs.python.org  Thu Jun  2 18:27:45 2011
From: report at bugs.python.org (Tim Koopman)
Date: Thu, 02 Jun 2011 16:27:45 +0000
Subject: [issue12241] email.header.Header encoding fails on empty header
In-Reply-To: <1307028314.79.0.859095515398.issue12241@psf.upfronthosting.co.za>
Message-ID: <1307032065.63.0.0147066663737.issue12241@psf.upfronthosting.co.za>


Tim Koopman <python.org at nandoe.net> added the comment:

Looking at the source of 3.2.1, it appears this was already solved. Sorry.

----------

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

From report at bugs.python.org  Thu Jun  2 19:10:40 2011
From: report at bugs.python.org (Kyle Keating)
Date: Thu, 02 Jun 2011 17:10:40 +0000
Subject: [issue12129] Document Object Model API - validation
In-Reply-To: <1305928931.2.0.716148568641.issue12129@psf.upfronthosting.co.za>
Message-ID: <1307034640.22.0.948698014306.issue12129@psf.upfronthosting.co.za>


Kyle Keating <kkeating at gmail.com> added the comment:

This looks to break pretty good... I did confirm this on 3.0, I'm guessing 3.2 is the same.

import sys
import xml.dom

doc = xml.dom.getDOMImplementation().createDocument(None, 'xml', None)
doc.firstChild.appendChild(doc.createElement('element00'))

element01 = doc.createElement('element01')
element01.setAttribute('attribute', "script><![CDATA[alert('script!');]]></script>")
doc.firstChild.appendChild(element01)

element02 = doc.createElement("script><![CDATA[alert('script!');]]></script>")
doc.firstChild.appendChild(element02)

element03 = doc.createElement("new line \n")

element03.setAttribute('attribute-name','new line \n')
doc.firstChild.appendChild(element03)

print doc.toprettyxml(indent="  ")

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
output:

<?xml version="1.0" ?>
<xml>
  <element/>
  <element01 attribute="script&gt;&lt;![CDATA[alert('script!');]]&gt;&lt;/script
&gt;"/>
  <script><![CDATA[alert('script!');]]></script>/>
  <new line
 attribute-name="new line
"/>
</xml>

----------

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

From report at bugs.python.org  Thu Jun  2 19:13:18 2011
From: report at bugs.python.org (Kyle Keating)
Date: Thu, 02 Jun 2011 17:13:18 +0000
Subject: [issue12129] Document Object Model API - validation
In-Reply-To: <1305928931.2.0.716148568641.issue12129@psf.upfronthosting.co.za>
Message-ID: <1307034798.0.0.972439879781.issue12129@psf.upfronthosting.co.za>


Kyle Keating <kkeating at gmail.com> added the comment:

oops, the first xml element in the output should read  "<element00/>" not "<element/>"

just a typo! don't get confused!

----------

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

From report at bugs.python.org  Thu Jun  2 20:11:01 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Jun 2011 18:11:01 +0000
Subject: [issue5384] mmap and exception type
In-Reply-To: <1235755397.37.0.107266248804.issue5384@psf.upfronthosting.co.za>
Message-ID: <1307038261.31.0.0142041813266.issue5384@psf.upfronthosting.co.za>


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

It is uncomfortable changing exception types have been a published API for over a decade, so I'll leave this one open for a bit so that others can comment.

Most of the changes in the patch are correct and match their counterparts for lists and strings.  The TypeError for slice deletion was correct as-is (it matches del 'abc'[1]).  The IndexError on slice assignment may be correct as-is (I'll do more research).  The from ValueError to SystemError is questionable.  Otherwise, the patch looks to be mostly correct (I'll give it a more thorough review later).

----------
assignee:  -> rhettinger
nosy: +rhettinger
priority: normal -> low

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

From report at bugs.python.org  Thu Jun  2 20:50:57 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 02 Jun 2011 18:50:57 +0000
Subject: [issue12244] cStringIO inconsistencies
In-Reply-To: <1307040657.77.0.338586690814.issue12244@psf.upfronthosting.co.za>
Message-ID: <1307040657.77.0.338586690814.issue12244@psf.upfronthosting.co.za>


New submission from Santoso Wijaya <santoso.wijaya at gmail.com>:

Observe:

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.
>>> from cStringIO import StringIO
>>> result = StringIO('Hello, ')
>>> result.write('world')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'cStringIO.StringI' object has no attribute 'write'
>>>
>>> result = StringIO()
>>> result.write('Hello, world')
>>> print result.getvalue()
Hello, world
>>>
>>> from StringIO import StringIO
>>> result = StringIO('Hello, ')
>>> result.write('world')
>>> print result.getvalue()
world,
>>>


Few things:
1. The error message says, "StringI" instead of "StringIO".
2. Why does a cStringIO.StringIO object instantiated with a starter string not have the `write` attribute?
3. Using the pure-Python equivalent, (2) succeeds but it overwrites the starter string?
4. Regardless, (2) and (3) are not consistent with each other.

----------
components: Library (Lib)
messages: 137490
nosy: santa4nt
priority: normal
severity: normal
status: open
title: cStringIO inconsistencies
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun  2 20:53:24 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Jun 2011 18:53:24 +0000
Subject: [issue12243] getpass.getuser works on OSX
In-Reply-To: <1307029704.02.0.858553376312.issue12243@psf.upfronthosting.co.za>
Message-ID: <1307040804.2.0.778816468477.issue12243@psf.upfronthosting.co.za>


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

I think you are correct that the Availability can be removed, since the actual limits of the support are exactly as complicated as the code that supports them, and should give *some* result on most (all?) platforms.  However, OS/X is certainly covered by the current one, since OS/X is a unix flavor.  At this point in time it might be worth doing a sweep through the docs to remove all occurrences of 'Macintosh', since we don't support OS/9 any more.  There look to be less than a dozen such references in the Python3 docs.

I'm adding Gregory to nosy to see if he thinks it is appropriate to remove the 'availability' entirely, since he implemented the fallback.

----------
nosy: +gregory.p.smith, r.david.murray
versions:  -Python 2.6, Python 3.1, Python 3.4

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

From report at bugs.python.org  Thu Jun  2 20:56:26 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Jun 2011 18:56:26 +0000
Subject: [issue12241] email.header.Header encoding fails on empty header
In-Reply-To: <1307028314.79.0.859095515398.issue12241@psf.upfronthosting.co.za>
Message-ID: <1307040986.54.0.960653054379.issue12241@psf.upfronthosting.co.za>


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

No problem.  It's too bad that regression slipped in to 3.2.0.  I probably fixed it by accident, since I rewrote a bunch of that code in 3.2.1 while fixing a different bug.

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Jun  2 21:47:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Jun 2011 19:47:10 +0000
Subject: [issue12245] Document the meaning of FLT_ROUNDS constants for
	sys.float_info
In-Reply-To: <1307044030.93.0.176037757521.issue12245@psf.upfronthosting.co.za>
Message-ID: <1307044030.93.0.176037757521.issue12245@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

>>> sys.float_info.rounds
1

----------
assignee: docs at python
components: Documentation
messages: 137493
nosy: docs at python, rhettinger
priority: normal
severity: normal
status: open
title: Document the meaning of FLT_ROUNDS constants for sys.float_info
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jun  2 22:07:15 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Jun 2011 20:07:15 +0000
Subject: [issue12244] cStringIO inconsistencies
In-Reply-To: <1307040657.77.0.338586690814.issue12244@psf.upfronthosting.co.za>
Message-ID: <1307045235.94.0.0290046695377.issue12244@psf.upfronthosting.co.za>


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

1. The class for read-only objects is called "StringI" (the one for read-write objects is "StringO").

2./3. This is documented: http://docs.python.org/library/stringio#cStringIO.StringIO

These differences between StringIO and cStringIO are unfortunate, but cannot be changed anymore in Python 2.  It's all different in Python 3 anyway, with io.StringIO being the successor to both.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Thu Jun  2 22:09:02 2011
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 02 Jun 2011 20:09:02 +0000
Subject: [issue12246] create installation path if it's non-existent
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

If I happen to not have the directory, $PREFIX/python3.3/site-packages, I get an erroneous message telling me that I don't write permissions.

----------
assignee: tarek
components: Distutils2
files: create-dir-if-nonexistent.diff
keywords: patch
messages: 137495
nosy: alexis, eric.araujo, tarek, tshepang
priority: normal
severity: normal
status: open
title: create installation path if it's non-existent
versions: Python 3.3
Added file: http://bugs.python.org/file22223/create-dir-if-nonexistent.diff

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

From report at bugs.python.org  Thu Jun  2 23:21:03 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 02 Jun 2011 21:21:03 +0000
Subject: [issue12244] cStringIO inconsistencies
In-Reply-To: <1307040657.77.0.338586690814.issue12244@psf.upfronthosting.co.za>
Message-ID: <1307049663.95.0.305632554457.issue12244@psf.upfronthosting.co.za>


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

>_< Should've read the docs again more carefully before submitting.

----------

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

From report at bugs.python.org  Fri Jun  3 00:49:06 2011
From: report at bugs.python.org (George Patterson)
Date: Thu, 02 Jun 2011 22:49:06 +0000
Subject: [issue12247] Finding subprocess.py depends on how IDLE is opened
In-Reply-To: <1307054946.0.0.524877875155.issue12247@psf.upfronthosting.co.za>
Message-ID: <1307054946.0.0.524877875155.issue12247@psf.upfronthosting.co.za>


New submission from George Patterson <geopascway at gmail.com>:

I'm uncertain this is a bug, but it seems persistent over several machines and I can't figure out where the issue lies.

Most of my troubleshooting has been on a MacBook Pro with Mac OS X version 10.6.7. I have a simple python script 'test.py':

  import subprocess
  subprocess.Popen(['xterm'])

If I run this script by opening it in IDLE using the mouse, it crashes. If I run the same script in an IDLE that I launch by typing 'idle' in a terminal, it doesn't crash. What's going on?  Is this a bug? Or am I just doing something terribly wrong?
Obviously, my interest is not in running this simple script, but it contains the minimum part of the real script which reproduces the error.  

I've repeated this error on one machine(MacBook Pro with Mac OS X version 10.6.7) using either of two versions of Python, 2.6.6 or 2.7.1.  On one machine(Mac Pro OS X version 10.6.7) using Python 2.6.6, on two other machines(IMacs with either OS X version 10.6.7 or 10.6.5) using Python 2.7.1.  I include below only the info for the 2.7.1.

Python 2.7.1 was the 32-bit version Mac OS X 32-bit i386/PPC Installer (2.7.1) for Mac OS X 10.3 through 10.6 [2] (sig) from here (http://www.python.org/download/releases/2.7.1/).



Details: 


1.  Launch IDLE by right clicking test.py and "open with" IDLE (2.7.1).  I "run module".  Pasted below are the contents from the Python Shell.  Included at the bottom is the sys.path for IDLE opened in this manner.
I've also find this error if I open the IDLE located in Applications/Python 2.7/ and then open "test.py" and run it.


Python 2.7.1 (r271:86882M, Nov 30 2010, 09:39:13) 
[GCC 4.0.1 (Apple Inc. build 5494)] on darwin
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART ================================
>>> 

Traceback (most recent call last):
  File "/Users/georgepatterson/test.py", line 2, in <module>
    subprocess.Popen(['xterm'])
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 672, in __init__
    errread, errwrite)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 1202, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
>>> import sys
>>> for p in sys.path: print p

/Users/georgepatterson
/Users/georgepatterson/Documents
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg
/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
>>> 




2.  Type "idle" in a terminal window.  Open test.py and "run module".
When run in this manner, the terminal window is opened properly.  I've pasted the contents of the Python Shell below with the sys.path also. 
In case it matters, "which idle" at the terminal prompt points here
/Library/Frameworks/Python.framework/Versions/2.7/bin/idle



Python 2.7.1 (r271:86882M, Nov 30 2010, 09:39:13) 
[GCC 4.0.1 (Apple Inc. build 5494)] on darwin
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART ================================
>>> 
>>> import sys
>>> for p in sys.path: print p

/Users/georgepatterson
/Library/Frameworks/Python.framework/Versions/2.7/bin
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg
/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
>>>

----------
components: IDLE
messages: 137497
nosy: George.Patterson
priority: normal
severity: normal
status: open
title: Finding subprocess.py depends on how IDLE is opened
type: crash
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Jun  3 01:03:04 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 02 Jun 2011 23:03:04 +0000
Subject: [issue12247] Finding subprocess.py depends on how IDLE is opened
In-Reply-To: <1307054946.0.0.524877875155.issue12247@psf.upfronthosting.co.za>
Message-ID: <1307055784.88.0.0454063420616.issue12247@psf.upfronthosting.co.za>


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

sys.path is probably not relevant here (it's used to import python modules). Can you print the value of os.environ['PATH'] instead?

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

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

From report at bugs.python.org  Fri Jun  3 01:15:58 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 02 Jun 2011 23:15:58 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1307056558.43.0.991148721675.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Attached is a complete patch. All tests pass.

Lib/test/support.py
 * Handle AttributeError, which Hirokazu noticed on pre-XP machines

Lib/test/test_os.py
 * This sets up a three-deep directory tree and creates a symbolic link in the middle (second) directory.
 * os.stat calls are tested from below, equal to, and above the symbolic link to make sure they work. This is what was broken with the previous os.stat implementation on Windows, as it used a method which only provided correct information (the reparse tag) when the stat call was made from the directory where the link originates from.

Modules/posixmodule.c
 * win32_read_link, now called win32_get_reparse_tag, was changed to just get the reparse tag and that's it. The tag is now only used when setting the mode attribute based on if the tag shows that this is a symlink directory or file.

 * The GetFinalPathNameByHandle dynamic loading and preparing was moved up in the file since it is again used for stat calls.

 * I removed the major duplication of stat implementations for both narrow and wide paths. Now there is just one implementation, win32_xstat_impl, which accepts a wide path and does the same work.

 * win32_xstat_impl now takes an approach where if there's a symlink to be traversed, e.g., for an os.stat call, the path is then re-opened without the flag to open the reparse tag, effectively following the link path. Then we pass the newly opened file handle to GetFinalPathNameByHandle and we can get back the target path, which we then pass recursively. There's no more depth stuff - we either try to follow the link in the above fashion or not.

 * win32_lstat was never being called from anywhere so it was removed.

 * win32_stat, which takes a narrow path, is now converted early to a wide path and passed into the win32_xstat_impl rather than maintaining two of the same functions like before.

----------
keywords: +needs review
Added file: http://bugs.python.org/file22224/issue12084.diff

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

From report at bugs.python.org  Fri Jun  3 01:32:34 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 02 Jun 2011 23:32:34 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

I'm making this a release blocker for 2.7.2 because I want to ensure that the change is deliberate and appropriate.  This is triggered by a bug report in Ubuntu where the change in behavior was noticed:

https://bugs.launchpad.net/nova/+bug/791221/+index

I have two problems with the change that I'd like to describe.  First is the NEWS file entry:

- Correct lookup of __dir__ on objects. Among other things, this causes errors
  besides AttributeError found on lookup to be propagated.

This isn't associated with a tracker issue, so it's hard to know why this change was made, or whether there was any discussion of its impact.

Second, is this change appropriate for a maintenance release?  What problem does it fix and is that worth breaking existing packages for it?

I'll attach a simple test program.  Run this under 2.7.1 and it works, run it under 2.7.2rc1 and you get a TypeError.

----------
assignee: benjamin.peterson
components: Interpreter Core
files: foo.py
messages: 137500
nosy: barry, benjamin.peterson
priority: release blocker
severity: normal
status: open
title: __dir__ semantics changed in Python 2.7.2
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file22225/foo.py

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

From report at bugs.python.org  Fri Jun  3 01:56:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Jun 2011 23:56:22 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307058982.74.0.28287537495.issue12248@psf.upfronthosting.co.za>


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

As I recall the issue that triggered the change was reported by Michael Foord, so I'm adding him as nosy too.

----------
nosy: +michael.foord, r.david.murray

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

From report at bugs.python.org  Fri Jun  3 02:08:05 2011
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 03 Jun 2011 00:08:05 +0000
Subject: [issue12249] add missing command
In-Reply-To: <1307059685.23.0.0593360384194.issue12249@psf.upfronthosting.co.za>
Message-ID: <1307059685.23.0.0593360384194.issue12249@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

It's not indicated where one should run the command 'make html' in the "Building the documentation" page, so when it failed for me when running it from the cpython distribution root, I was left a little puzzled, searching where the problem might lie (wasting time).

----------
assignee: docs at python
components: Documentation
files: add-missing-command.diff
keywords: patch
messages: 137502
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: add missing command
versions: Python 3.3
Added file: http://bugs.python.org/file22226/add-missing-command.diff

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

From report at bugs.python.org  Fri Jun  3 02:14:52 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 03 Jun 2011 00:14:52 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307060092.26.0.772131908489.issue12248@psf.upfronthosting.co.za>


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

Hmm, that behaviour looks unrelated to the specific problem Michael reported.

The initial problem in this space was that defining __dir__() completely determined the result of dir() calls, but object.__dir__() didn't actually work, so you couldn't easily get the standard list of attributes in order to supplement it.

I don't believe there is any reason to have tightened up the type constraints while fixing that - dir() should be returning sorted(obj.__dir__()) and not caring about the exact return type of the magic method.

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

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

From report at bugs.python.org  Fri Jun  3 02:46:13 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Fri, 03 Jun 2011 00:46:13 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307061973.86.0.0629895120523.issue12248@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/issue12248>
_______________________________________

From report at bugs.python.org  Fri Jun  3 03:42:43 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Jun 2011 01:42:43 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307065363.52.0.557036099161.issue12248@psf.upfronthosting.co.za>


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

> I don't believe there is any reason to have tightened up
> the type constraints while fixing that - dir() should be
> returning sorted(obj.__dir__()) and not caring about the 
> exact return type of the magic method.

+1

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

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

From report at bugs.python.org  Fri Jun  3 05:14:54 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Jun 2011 03:14:54 +0000
Subject: [issue12247] Finding subprocess.py depends on how IDLE is opened
In-Reply-To: <1307054946.0.0.524877875155.issue12247@psf.upfronthosting.co.za>
Message-ID: <1307070894.68.0.730823221753.issue12247@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The difference in behavior you are seeing does indeed have to do with the PATH environment variable.  When you start IDLE via a terminal shell, it inherits the PATH value from your shell environment.  path_helper(8) sets the default value for a login shell PATH by consulting the entries in /etc/paths.d/. On OS X 10.6, that includes /usr/X11/bin, which is where xterm is located.  However, when you launch IDLE from the Finder, either by double-clicking on the IDLE app icon or by opening a file using IDLE as the default app (as you are doing in test 1), a shell is not involved and the PATH inherited by the app environment is slightly different.  In paticular, /etc/paths.d is not consulted and so /usr/X11/bin is not on the path.  As Amaury suggested, you should be able to see that by looking at PATH in both cases.  For IDLE.app launched from the Finder, you'll probably see something like:

   >>> os.environ['PATH']
   '/usr/bin:/bin:/usr/sbin:/sbin'

While it is possible to change the default environment variables for processes launched (see http://developer.apple.com/library/mac/#qa/qa1067/_index.html), it is rarely necessary or desirable to do that.  For this case, the simplest solution is to supply the absolute path to 'xterm':

  import subprocess
  subprocess.Popen(['/usr/X11/bin/xterm'])

Or you could get fancier by modifying PATH yourself.

----------
nosy: +ned.deily
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: crash -> 

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

From report at bugs.python.org  Fri Jun  3 08:37:19 2011
From: report at bugs.python.org (stefanholek)
Date: Fri, 03 Jun 2011 06:37:19 +0000
Subject: [issue12186] readline.replace_history_item still leaks memory
In-Reply-To: <1306412402.14.0.859641157612.issue12186@psf.upfronthosting.co.za>
Message-ID: <1307083039.08.0.264377780956.issue12186@psf.upfronthosting.co.za>


stefanholek <stefan at epy.co.at> added the comment:

These undo lists come into existence when history entries are edited interactively (Arrow-Up, edit line, Arrow-Up, edit line, Enter -> undo list of first history entry leaks).

----------
components: +Extension Modules
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/issue12186>
_______________________________________

From report at bugs.python.org  Fri Jun  3 10:02:12 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jun 2011 08:02:12 +0000
Subject: [issue12250] regrtest: make --timeout explicit
In-Reply-To: <1307088132.85.0.485595882281.issue12250@psf.upfronthosting.co.za>
Message-ID: <1307088132.85.0.485595882281.issue12250@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

The implicit timeout in regrtest.py makes it harder to write automated
test scripts for 3rd party modules. First, you have to remember to
set --timeout=0 for long running tests. Then, you have to remember
not to use the --timeout option when compiling --without-threads.

I'd much prefer that there's no timeout unless explicitly specified.
For the buildbots, I think this could be done in the Makefile.

----------
components: Tests
messages: 137507
nosy: haypo, michael.foord, skrah
priority: normal
severity: normal
status: open
title: regrtest: make --timeout explicit
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun  3 11:15:26 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 03 Jun 2011 09:15:26 +0000
Subject: [issue11504] test_subprocess failure
In-Reply-To: <1300122839.15.0.162000856682.issue11504@psf.upfronthosting.co.za>
Message-ID: <1307092526.11.0.573109163799.issue11504@psf.upfronthosting.co.za>


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

All stable buildbots appear to be green, so closing...

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

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

From report at bugs.python.org  Fri Jun  3 11:28:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jun 2011 09:28:27 +0000
Subject: [issue12250] regrtest: make --timeout explicit
In-Reply-To: <1307088132.85.0.485595882281.issue12250@psf.upfronthosting.co.za>
Message-ID: <201106031128.25219.victor.stinner@haypocalc.com>


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

Le vendredi 03 juin 2011 10:02:12, vous avez ?crit :
> The implicit timeout in regrtest.py makes it harder to write automated
> test scripts for 3rd party modules. First, you have to remember to
> set --timeout=0 for long running tests.

Ah? Which test is too long for the default timeout? On which kind of computer? 
It's difficult to choose a timeout working on any kind of computer. We use one 
hour because buildbots are configured with a timeout of something like 70 
minutes (just a little bit longer than the regrtest timeout).

> Then, you have to remember not to use the --timeout option when
> compiling --without-threads.

We can change regrtest to just print a warning, and not exit, if Python has no 
thread support and --timeout option is used.

... or we can can improve faulthandler to use SIGALARM+alarm() to implement 
faulthandler.dump_tracebacks_later(), which is already done in the 3rd party 
version of the module. Problem with SIGALRM: it interrupts the current system 
call which fails with EINTR (except for some system calls able to "restart"). 
This problem doesn't matter for regrtest because regrtest uses timeout=True 
and so we exit immediatly on SIGALRM. Another bigger problems: some Python 
tests uses SIGALRM with alarm(), and alarm() is global to the process.

Well, the first solution (display a warning in regrtest, but don't exit) looks 
simpler :-)

> I'd much prefer that there's no timeout unless explicitly specified.
> For the buildbots, I think this could be done in the Makefile.

I set a default timeout for buildbots, because I don't know how to change how 
regrtest is started on all buildbots, but you are right: it can be done in 
"make buildbottests".

----------

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

From report at bugs.python.org  Fri Jun  3 11:47:09 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 03 Jun 2011 09:47:09 +0000
Subject: [issue12251] subprocess(...,
	stdout=sys.stderr) closes stderr for child
In-Reply-To: <1307094428.89.0.00113133109323.issue12251@psf.upfronthosting.co.za>
Message-ID: <1307094428.89.0.00113133109323.issue12251@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

How to test:
----------------
#! /usr/bin/python
import subprocess, sys

# will print err to sys.stderr
subprocess.call(['rmdir', '/no_such_dir'])

# will NOT print err to sys.stderr
subprocess.call(['rmdir', '/no_such_dir'], stdout=sys.stderr)
----------------

According to strace, in child process:
-----------------
dup2(2, 1) // that's what I expect, okay
close(2) // that's I was not expect, so bug here
execve(...)
-----------------

Bug is in subprocess.py:
(search for "dup2" in file)
I do not known how to fix correctly. Logick in this module is brain damaged in some places.

-----------------------------
# Dup fds for child
if p2cread is not None:
    os.dup2(p2cread, 0)
if c2pwrite is not None:
    os.dup2(c2pwrite, 1)
if errwrite is not None:
    os.dup2(errwrite, 2)

# Close pipe fds.  Make sure we don't close the same
# fd more than once, or standard fds.
if p2cread is not None and p2cread not in (0,):
    os.close(p2cread)
if c2pwrite is not None and c2pwrite not in (p2cread, 1):
    os.close(c2pwrite)
if errwrite is not None and errwrite not in (p2cread, c2pwrite, 2):
    os.close(errwrite)
-------------------------

----------
components: Library (Lib)
messages: 137510
nosy: mmarkk
priority: normal
severity: normal
status: open
title: subprocess(..., stdout=sys.stderr) closes stderr for child
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/issue12251>
_______________________________________

From report at bugs.python.org  Fri Jun  3 11:48:18 2011
From: report at bugs.python.org (Alexey Smirnov)
Date: Fri, 03 Jun 2011 09:48:18 +0000
Subject: [issue12251] subprocess(...,
	stdout=sys.stderr) closes stderr for child
In-Reply-To: <1307094428.89.0.00113133109323.issue12251@psf.upfronthosting.co.za>
Message-ID: <1307094498.24.0.996400805427.issue12251@psf.upfronthosting.co.za>


Changes by Alexey Smirnov <alexey.smirnov at gmx.com>:


----------
nosy: +alexey-smirnov

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

From report at bugs.python.org  Fri Jun  3 11:55:30 2011
From: report at bugs.python.org (=?utf-8?q?Han=C3=B6fner_Harald?=)
Date: Fri, 03 Jun 2011 09:55:30 +0000
Subject: [issue12252] '\u' in unicode raw string raise an syntax error
In-Reply-To: <1307094930.07.0.437131076278.issue12252@psf.upfronthosting.co.za>
Message-ID: <1307094930.07.0.437131076278.issue12252@psf.upfronthosting.co.za>


New submission from Han?fner Harald <ha.harry at yahoo.de>:

The follow code:
s = ur"c:\that\is\a\new\unicode\path"

raise the follow error:
SyntaxError: (unicode error) 'rawunicodeescape' codec can't decode bytes in position 10-11: truncated \uXXXX

That is already corrected in Py 3 builds.

----------
components: Interpreter Core
messages: 137511
nosy: HarryH
priority: normal
severity: normal
status: open
title: '\u' in unicode raw string raise an syntax error
type: compile error
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Jun  3 12:05:38 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 03 Jun 2011 10:05:38 +0000
Subject: [issue12251] subprocess(...,
	stdout=sys.stderr) closes stderr for child
In-Reply-To: <1307094428.89.0.00113133109323.issue12251@psf.upfronthosting.co.za>
Message-ID: <1307095538.57.0.15617650314.issue12251@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

patch (was not tested) attached

----------
keywords: +patch
Added file: http://bugs.python.org/file22227/z.patch

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

From report at bugs.python.org  Fri Jun  3 12:11:04 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 03 Jun 2011 10:11:04 +0000
Subject: [issue12252] '\u' in unicode raw string raise an syntax error
In-Reply-To: <1307094930.07.0.437131076278.issue12252@psf.upfronthosting.co.za>
Message-ID: <1307095864.74.0.203068775216.issue12252@psf.upfronthosting.co.za>


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

Even in "raw" unicode strings, \u is processed as an escape sequence; see the very last paragraph of
http://docs.python.org/reference/lexical_analysis.html#string-literals

Yes, this can be surprising, and was changed with Python 3.
Python 2 versions can't be changed for compatibility reasons.

----------
nosy: +amaury.forgeotdarc
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Fri Jun  3 12:26:57 2011
From: report at bugs.python.org (Evgeny Tarasov)
Date: Fri, 03 Jun 2011 10:26:57 +0000
Subject: [issue12251] subprocess(...,
	stdout=sys.stderr) closes stderr for child
In-Reply-To: <1307094428.89.0.00113133109323.issue12251@psf.upfronthosting.co.za>
Message-ID: <1307096817.3.0.568280104927.issue12251@psf.upfronthosting.co.za>


Changes by Evgeny Tarasov <etarasov.ekb at gmail.com>:


----------
nosy: +Evgeny.Tarasov

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

From report at bugs.python.org  Fri Jun  3 12:36:39 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jun 2011 10:36:39 +0000
Subject: [issue12250] regrtest: make --timeout explicit
In-Reply-To: <1307088132.85.0.485595882281.issue12250@psf.upfronthosting.co.za>
Message-ID: <1307097399.41.0.620228901813.issue12250@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

STINNER Victor <report at bugs.python.org> wrote:
> > The implicit timeout in regrtest.py makes it harder to write automated
> > test scripts for 3rd party modules. First, you have to remember to
> > set --timeout=0 for long running tests.
>
> Ah? Which test is too long for the default timeout? On which kind of computer?

I don't know about the regular tests, though I think it might be possible
to exceed the timeout if you run the tests on a very slow machine under
Valgrind.


For cdecimal, I've integrated a facility into test_decimal.py to test
all failures of Python API functions in a systematic manner. This
works by wrapping all test_* methods in a function that first counts
the number of API calls in a test case, then reruns the test case
n times with a deliberate failure point moved ahead each time.

This facility is of course not enabled by default and requires a small
patch to _decimal.c. When enabled, run times easily exceed 1 hour,
especially with Valgrind.

The broader point is that due to the excellent refleak counting
facility people might use (I hope!) regrtest.py for 3rd party
modules, where we don't know the run times of the tests.


> > Then, you have to remember not to use the --timeout option when
> > compiling --without-threads.
>
> We can change regrtest to just print a warning, and not exit, if Python has no
> thread support and --timeout option is used.

This would already help a lot. Currently I have to do this in my test
scripts:

    timeout="--timeout=0"
    if [ X"$args" = X"--without-threads" ]; then
        timeout=""
    fi



> Well, the first solution (display a warning in regrtest, but don't exit) looks
> simpler :-)

Indeed. :)


> > I'd much prefer that there's no timeout unless explicitly specified.
> > For the buildbots, I think this could be done in the Makefile.
>
> I set a default timeout for buildbots, because I don't know how to change how
> regrtest is started on all buildbots, but you are right: it can be done in
> "make buildbottests".

This would be my favorite solution. Of course other people might like the
default timeout - it's hard to satisfy everyone.

----------

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

From report at bugs.python.org  Fri Jun  3 12:42:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jun 2011 10:42:14 +0000
Subject: [issue12251] subprocess(...,
	stdout=sys.stderr) closes stderr for child
In-Reply-To: <1307094428.89.0.00113133109323.issue12251@psf.upfronthosting.co.za>
Message-ID: <1307097734.93.0.592594532373.issue12251@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/issue12251>
_______________________________________

From report at bugs.python.org  Fri Jun  3 12:53:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 03 Jun 2011 10:53:54 +0000
Subject: [issue12250] regrtest: make --timeout explicit
In-Reply-To: <1307088132.85.0.485595882281.issue12250@psf.upfronthosting.co.za>
Message-ID: <E1QSS0j-0004xi-Jp@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f69a2716d433 by Victor Stinner in branch 'default':
Close #12250: Disable the regrtest timeout by default
http://hg.python.org/cpython/rev/f69a2716d433

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Jun  3 13:00:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 03 Jun 2011 11:00:09 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <E1QSS6p-0005Xg-8S@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 277bbe6cae53 by Charles-Fran?ois Natali in branch 'default':
Issue #12196: Make test.support's requires_linux_version a decorator.
http://hg.python.org/cpython/rev/277bbe6cae53

----------

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

From report at bugs.python.org  Fri Jun  3 13:55:07 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 03 Jun 2011 11:55:07 +0000
Subject: [issue12251] subprocess(...,
	stdout=sys.stderr) closes stderr for child
In-Reply-To: <1307094428.89.0.00113133109323.issue12251@psf.upfronthosting.co.za>
Message-ID: <1307102107.87.0.848251678241.issue12251@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

It's a duplicate of issue #10806, fixed in 2.7, 3.1 and 3.2.
Closing.

----------
nosy: +charles-francois.natali
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Subprocess error if fds 0,1,2 are closed

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

From report at bugs.python.org  Fri Jun  3 15:23:52 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 03 Jun 2011 13:23:52 +0000
Subject: [issue12251] subprocess(...,
	stdout=sys.stderr) closes stderr for child
In-Reply-To: <1307094428.89.0.00113133109323.issue12251@psf.upfronthosting.co.za>
Message-ID: <1307107432.67.0.383373750471.issue12251@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

Why not to backport to python 2.6 ? this is the bug, not a feature.

----------

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

From report at bugs.python.org  Fri Jun  3 16:27:31 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Jun 2011 14:27:31 +0000
Subject: [issue12251] subprocess(...,
	stdout=sys.stderr) closes stderr for child
In-Reply-To: <1307094428.89.0.00113133109323.issue12251@psf.upfronthosting.co.za>
Message-ID: <1307111251.68.0.6432826942.issue12251@psf.upfronthosting.co.za>


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

Because 2.6 is in security-fix-only mode.

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

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

From report at bugs.python.org  Fri Jun  3 16:30:30 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Fri, 03 Jun 2011 14:30:30 +0000
Subject: [issue12185] Decimal documentation lists "first" and "second"
	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1307111430.36.0.0672031736336.issue12185@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Hi all,
that is my first contribution. Please let me know if all it's OK.

Thanks in advance !

----------
keywords: +patch
nosy: +francismb
Added file: http://bugs.python.org/file22228/issue_12185.patch

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

From report at bugs.python.org  Fri Jun  3 16:58:54 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Fri, 03 Jun 2011 14:58:54 +0000
Subject: [issue12185] Decimal documentation lists "first" and "second"
	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1307113134.77.0.29505263014.issue12185@psf.upfronthosting.co.za>


Adam Woodbeck <adam.woodbeck at gmail.com> added the comment:

Hi Francisco,

I finally found time to create a patch for this issue.  I was just saving the patch I wrote as your update arrived in my inbox.  I've included my patch for good measure.  It's better to have two proposed patches than none at all in my opinion.

Adam

----------
Added file: http://bugs.python.org/file22229/issue_12185-ajw.patch

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

From report at bugs.python.org  Fri Jun  3 17:05:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 15:05:42 +0000
Subject: [issue12253] Document packaging.manifest and packaging.errors
In-Reply-To: <1307113542.31.0.0409557566513.issue12253@psf.upfronthosting.co.za>
Message-ID: <1307113542.31.0.0409557566513.issue12253@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I am working on a patch to document manifest.Manifest methods and list all exceptions defined in errors.

----------
assignee: eric.araujo
components: Distutils2, Documentation
messages: 137522
nosy: alexis, eric.araujo
priority: normal
severity: normal
status: open
title: Document packaging.manifest and packaging.errors
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun  3 17:13:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Jun 2011 15:13:17 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1307113997.68.0.434319238356.issue12014@psf.upfronthosting.co.za>


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

The documentation is, in principle, wrong.  The actual authority for the "correct" implementation is PEP3101, which says the following:

    The str.format() function will have
    a minimalist parser which only attempts to figure out when it is
    "done" with an identifier (by finding a '.' or a ']', or '}',
    etc.).

Changing that specification would require a discussion on python-dev.

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

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

From report at bugs.python.org  Fri Jun  3 17:14:39 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Jun 2011 15:14:39 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1307114079.61.0.101628737683.issue12014@psf.upfronthosting.co.za>


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

Note that the PEP also explicitly addresses your concern about getattr, as well (validation of the name is delegated to the object's __getattr__).

----------

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

From report at bugs.python.org  Fri Jun  3 17:18:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 15:18:42 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1307114322.57.0.351608664647.issue11197@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/issue11197>
_______________________________________

From report at bugs.python.org  Fri Jun  3 17:19:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 15:19:53 +0000
Subject: [issue1669349] make install fails if no previous Python installation
Message-ID: <1307114393.82.0.280610412722.issue1669349@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/issue1669349>
_______________________________________

From report at bugs.python.org  Fri Jun  3 17:33:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 15:33:52 +0000
Subject: [issue11357] Add support for PEP 381 Mirror Authenticity
In-Reply-To: <1298948795.56.0.864012658533.issue11357@psf.upfronthosting.co.za>
Message-ID: <1307115232.6.0.356040454184.issue11357@psf.upfronthosting.co.za>


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


----------
title: Add support for PEP 381 -- Mirror Authenticity -> Add support for PEP 381 Mirror Authenticity
versions: +Python 3.3 -3rd party

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

From report at bugs.python.org  Fri Jun  3 17:34:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 15:34:26 +0000
Subject: [issue12231] regrtest: add -k and -K options to filter tests by
	function/file names
In-Reply-To: <1306886173.49.0.536773734975.issue12231@psf.upfronthosting.co.za>
Message-ID: <1307115266.5.0.722864281829.issue12231@psf.upfronthosting.co.za>


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

How about reusing unittest discovery in regrtest?

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

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

From report at bugs.python.org  Fri Jun  3 17:36:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 15:36:04 +0000
Subject: [issue12234] unittest2 could enable regex debugging for more
	information
In-Reply-To: <1306933404.89.0.697079292496.issue12234@psf.upfronthosting.co.za>
Message-ID: <1307115364.68.0.333134781563.issue12234@psf.upfronthosting.co.za>


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

This sounds non-trivial to implement.  Do you have any concrete ideas or a proof of concept?

----------
nosy: +eric.araujo, ezio.melotti, michael.foord
versions: +Python 3.3 -Python 2.7

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

From report at bugs.python.org  Fri Jun  3 17:39:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 15:39:17 +0000
Subject: [issue12237] Document how to open non-default webbrowser
In-Reply-To: <1307006042.24.0.905858439151.issue12237@psf.upfronthosting.co.za>
Message-ID: <1307115557.56.0.0588300247693.issue12237@psf.upfronthosting.co.za>


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

Hello.  This tracker is used to report bugs and file feature requests for Python itself, not request help (mailing list such as http://mail.python.org/pipermail/python-list/ are appropriate venues to ask for for help).  I?m changing your question to a bug report about missing documentation.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, eric.araujo
stage:  -> needs patch
title: how to open non defult browser? -> Document how to open non-default webbrowser
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jun  3 17:39:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 15:39:41 +0000
Subject: [issue12240] Allow multiple setup_hooks
In-Reply-To: <1307026779.27.0.653754848212.issue12240@psf.upfronthosting.co.za>
Message-ID: <1307115581.92.0.838939047967.issue12240@psf.upfronthosting.co.za>


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

I can?t see why not.  Would you like to work on a patch?

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

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

From report at bugs.python.org  Fri Jun  3 17:42:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 15:42:38 +0000
Subject: [issue12238] Readline module loading in interactive mode
In-Reply-To: <1307015860.03.0.129842780518.issue12238@psf.upfronthosting.co.za>
Message-ID: <1307115758.49.0.717635539221.issue12238@psf.upfronthosting.co.za>


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

+1 to what David said.  See also #5753.

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

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

From report at bugs.python.org  Fri Jun  3 17:43:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 15:43:30 +0000
Subject: [issue12243] getpass.getuser works on OSX
In-Reply-To: <1307029704.02.0.858553376312.issue12243@psf.upfronthosting.co.za>
Message-ID: <1307115810.12.0.735006409151.issue12243@psf.upfronthosting.co.za>


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

Yes, it?s unclear whether Unix in the docs included Mac OS X or not.

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

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

From report at bugs.python.org  Fri Jun  3 17:44:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 15:44:44 +0000
Subject: [issue12246] create installation path if it's non-existent
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307115884.1.0.572456425156.issue12246@psf.upfronthosting.co.za>


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

This looks like an invalid bug to me; Python itself creates the site-packages directory, with a README file if I remember correctly.  If the sysadmin removes the directory, it?s their problem, not a Python bug.  Do you agree?

----------

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

From report at bugs.python.org  Fri Jun  3 17:47:40 2011
From: report at bugs.python.org (Roman Alexeev)
Date: Fri, 03 Jun 2011 15:47:40 +0000
Subject: [issue12254] PEP-3107 has a wrong attribute name for function
	annotations
In-Reply-To: <1307116060.53.0.995138421611.issue12254@psf.upfronthosting.co.za>
Message-ID: <1307116060.53.0.995138421611.issue12254@psf.upfronthosting.co.za>


New submission from Roman Alexeev <letit.bee at gmail.com>:

The name of the attribute holding annotations is `__annotations__`, not `func_annotations` as PEP-3107 says.

----------
assignee: docs at python
components: Documentation
messages: 137532
nosy: Roman.Alexeev, docs at python
priority: normal
severity: normal
status: open
title: PEP-3107 has a wrong attribute name for function annotations

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

From report at bugs.python.org  Fri Jun  3 17:47:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 15:47:52 +0000
Subject: [issue12249] add missing command
In-Reply-To: <1307059685.23.0.0593360384194.issue12249@psf.upfronthosting.co.za>
Message-ID: <1307116072.0.0.51026958669.issue12249@psf.upfronthosting.co.za>


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

Your patch adds the cd before running make, but other examples and filenames (for example :file:`tools/sphinx`) are also relative to Doc.  How about adding something like this after the very first paragraph:

All commands in this document should be run from the :file:`Doc` directory of a Python checkout; all file and directory names are also relative to :file:`Doc`.

----------
nosy: +eric.araujo, georg.brandl

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

From report at bugs.python.org  Fri Jun  3 17:48:43 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Jun 2011 15:48:43 +0000
Subject: [issue12185] Decimal documentation lists "first" and "second"
	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1307116123.8.0.185593268272.issue12185@psf.upfronthosting.co.za>


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

I'm not sure this improves the docs.  Will give it more thought and thorough review at a later date.  Also, I will compare it to the "docstrings" in the spec itself.

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

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

From report at bugs.python.org  Fri Jun  3 17:49:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 15:49:52 +0000
Subject: [issue12200] bdist_wininst install_script not run on uninstall
In-Reply-To: <1306548527.55.0.138367912737.issue12200@psf.upfronthosting.co.za>
Message-ID: <1307116192.41.0.825960410361.issue12200@psf.upfronthosting.co.za>


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

If it?s not too much hassle for you and if it doesn?t improve maintenance costs, we?d feel safer with a test.

Martin, could you review this patch?

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

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

From report at bugs.python.org  Fri Jun  3 17:50:04 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 03 Jun 2011 15:50:04 +0000
Subject: [issue12246] create installation path if it's non-existent
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307116204.28.0.705975127624.issue12246@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This is probably because Tshepang works in a dev environment.

I think we should have a nice message like "The installation path xxx seems not to exist, aborting installation"

----------

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

From report at bugs.python.org  Fri Jun  3 17:51:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 15:51:06 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307116266.11.0.525812971085.issue12248@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/issue12248>
_______________________________________

From report at bugs.python.org  Fri Jun  3 17:52:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 15:52:48 +0000
Subject: [issue12246] create installation path if it's non-existent
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307116368.44.0.958065710201.issue12246@psf.upfronthosting.co.za>


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

Hm, in my dev environment (checkout of 3.3), site-packages exists.

----------

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

From report at bugs.python.org  Fri Jun  3 17:58:47 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 03 Jun 2011 15:58:47 +0000
Subject: [issue12246] create installation path if it's non-existent
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307116727.42.0.302831253716.issue12246@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Strange, you should get a /usr/[local]/lib/python3.3/site-packages when you just run "./configure; make"

It looks like you have a dev environment that has installed some stuff

----------

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

From report at bugs.python.org  Fri Jun  3 17:58:58 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 03 Jun 2011 15:58:58 +0000
Subject: [issue12246] create installation path if it's non-existent
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307116738.51.0.289357855691.issue12246@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

s/should get/should not get/

----------

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

From report at bugs.python.org  Fri Jun  3 18:00:18 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Jun 2011 16:00:18 +0000
Subject: [issue12243] getpass.getuser works on OSX
In-Reply-To: <1307029704.02.0.858553376312.issue12243@psf.upfronthosting.co.za>
Message-ID: <1307116818.93.0.678834690105.issue12243@psf.upfronthosting.co.za>


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

Well, let's make it clear then.  What about replacing the text-only "Availability" with a directive that renders into a link that displays what the individual values mean?

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

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

From report at bugs.python.org  Fri Jun  3 18:02:05 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Jun 2011 16:02:05 +0000
Subject: [issue12249] add missing command
In-Reply-To: <1307059685.23.0.0593360384194.issue12249@psf.upfronthosting.co.za>
Message-ID: <1307116925.16.0.0417130611063.issue12249@psf.upfronthosting.co.za>


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

I actually like the "cd Doc" inclusion; it makes it very clear what is going on.

----------

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

From report at bugs.python.org  Fri Jun  3 18:03:39 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Jun 2011 16:03:39 +0000
Subject: [issue12243] getpass.getuser works on OSX
In-Reply-To: <1307029704.02.0.858553376312.issue12243@psf.upfronthosting.co.za>
Message-ID: <1307117019.23.0.0950918685138.issue12243@psf.upfronthosting.co.za>


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

Only because we had Macintosh in there.  We don't mention OS/X explicitly anywhere else in the docs that I could find (except one prose mention in the logging docs).

----------

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

From report at bugs.python.org  Fri Jun  3 18:04:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 16:04:57 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1307117097.48.0.869461066234.issue11751@psf.upfronthosting.co.za>


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

Hi!  I cleaned up your patch and fixed a bug: you have to call sort before calling remove_duplicates (the result in your patch had two 'a' entries).

> One line was marked as excluded because it was a "this cannot happen"
> error, and I agreed.
How about we add a test to make this it cannot happen and then remove the line?

I also ported it to packaging, the replacement for distutils; I get this failure:

FAIL: test_process_template (__main__.ManifestTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/packaging/tests/test_manifest.py", line 166, in test_process_template
    action)
AssertionError: PackagingTemplateError not raised by _process_template_line

I haven?t investigated if the test is wrong or the code buggy yet; do you have any insight?

----------
status: pending -> open
title: Increase distutils.filelist test coverage -> Increase distutils.filelist / packaging.manifest test coverage
versions:  -Python 3.1
Added file: http://bugs.python.org/file22230/distutils-filelist.diff

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

From report at bugs.python.org  Fri Jun  3 18:05:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 16:05:05 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1307117105.65.0.770858909884.issue11751@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file22231/packaging-manifest.diff

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

From report at bugs.python.org  Fri Jun  3 18:07:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 16:07:40 +0000
Subject: [issue3974] collections.namedtuple uses exec to create new classes
In-Reply-To: <1222430514.93.0.950826754089.issue3974@psf.upfronthosting.co.za>
Message-ID: <1307117260.5.0.633590083684.issue3974@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/issue3974>
_______________________________________

From report at bugs.python.org  Fri Jun  3 18:09:19 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Jun 2011 16:09:19 +0000
Subject: [issue12243] getpass.getuser works on OSX
In-Reply-To: <1307029704.02.0.858553376312.issue12243@psf.upfronthosting.co.za>
Message-ID: <1307117359.76.0.259723610385.issue12243@psf.upfronthosting.co.za>


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

Georg: our post seem to have crossed despite Roundup's attempts at locking.  +1 to your idea about the directive.

----------

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

From report at bugs.python.org  Fri Jun  3 18:14:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 16:14:29 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1307117669.63.0.268072449257.issue9516@psf.upfronthosting.co.za>


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

I ported the patch to packaging.  Please test.

----------
components: +Distutils2
nosy: +alexis
status: closed -> open
versions:  -Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22232/darwin-target-sysconfig-p7g.diff

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

From report at bugs.python.org  Fri Jun  3 18:17:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 16:17:06 +0000
Subject: =?utf-8?q?=5Bissue12249=5D_Document_working_dir_for_=E2=80=9Cmake_html?=
	=?utf-8?b?4oCd?=
In-Reply-To: <1307059685.23.0.0593360384194.issue12249@psf.upfronthosting.co.za>
Message-ID: <1307117826.83.0.590577556921.issue12249@psf.upfronthosting.co.za>


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

Fair enough.  If you think it?s enough to let people know that all paths in :file: roles are relative to Doc, then I can commit it.

----------
title: add missing command -> Document working dir for ?make html?
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jun  3 18:18:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 16:18:58 +0000
Subject: [issue12246] create installation path if it's non-existent
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307117938.37.0.93511317422.issue12246@psf.upfronthosting.co.za>


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

Ah, I understand; I have a $srcdir/Lib/site-packages directory, but packaging wants to install into $prefix/site-packages, which does not exist.  +1 to adding a nice message.  Tshepang, would you like to update your patch?

----------

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

From report at bugs.python.org  Fri Jun  3 18:22:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 16:22:06 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1307118126.5.0.0112371527487.issue12226@psf.upfronthosting.co.za>


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

Patch needs to update the default server in packaging too.

----------

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

From report at bugs.python.org  Fri Jun  3 18:22:56 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Jun 2011 16:22:56 +0000
Subject: =?utf-8?q?=5Bissue12249=5D_Document_working_dir_for_=E2=80=9Cmake_html?=
	=?utf-8?b?4oCd?=
In-Reply-To: <1307059685.23.0.0593360384194.issue12249@psf.upfronthosting.co.za>
Message-ID: <1307118176.0.0.609198064908.issue12249@psf.upfronthosting.co.za>


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

It's fine, yes.

----------

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

From report at bugs.python.org  Fri Jun  3 18:26:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 16:26:27 +0000
Subject: [issue12214] platform module can't detect archlinux distribution
In-Reply-To: <1306755980.67.0.396964353848.issue12214@psf.upfronthosting.co.za>
Message-ID: <1307118387.41.0.723393226731.issue12214@psf.upfronthosting.co.za>


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

Thanks for the patch.  Please join the discussion on the other bug report.

----------
nosy: +eric.araujo
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Add support for Arch	Linux to platform.linux_distributions()
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Jun  3 18:38:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 16:38:31 +0000
Subject: [issue11993] Use sub-second resolution to determine if a file is newer
In-Reply-To: <1304475832.41.0.871788475686.issue11993@psf.upfronthosting.co.za>
Message-ID: <1307119111.03.0.320521728044.issue11993@psf.upfronthosting.co.za>


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

For the resolution problem, see #11457.

----------

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

From report at bugs.python.org  Fri Jun  3 18:39:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 16:39:17 +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: <1307119157.48.0.757733749663.issue11933@psf.upfronthosting.co.za>


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

Can you test this patch?

----------
keywords: +patch
Added file: http://bugs.python.org/file22233/fix-newer-mtime.diff

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

From report at bugs.python.org  Fri Jun  3 18:42:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 16:42:25 +0000
Subject: [issue12255] Make VCSes ignore shared libpython
In-Reply-To: <1307119345.93.0.971452096543.issue12255@psf.upfronthosting.co.za>
Message-ID: <1307119345.93.0.971452096543.issue12255@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

When compiling with --enable-shared, the libpython file is not ignored by Mercurial (or Bazaar, I guess).  Any objection to the attached patch?  I used a wildcard, but could also hard-code the full filename with a fixed shared lib number.

----------
assignee: eric.araujo
files: ignore-patterns.diff
keywords: needs review, patch
messages: 137553
nosy: eric.araujo
priority: normal
severity: normal
stage: commit review
status: open
title: Make VCSes ignore shared libpython
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22234/ignore-patterns.diff

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

From report at bugs.python.org  Fri Jun  3 18:48:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 16:48:03 +0000
Subject: [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1307119683.67.0.588795528455.issue12204@psf.upfronthosting.co.za>


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

A note sounds good.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core, Unicode
nosy: +docs at python, eric.araujo
versions: +Python 2.7 -Python 3.1

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

From report at bugs.python.org  Fri Jun  3 18:55:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 16:55:07 +0000
Subject: [issue12254] PEP-3107 has a wrong attribute name for function
	annotations
In-Reply-To: <1307116060.53.0.995138421611.issue12254@psf.upfronthosting.co.za>
Message-ID: <1307120107.11.0.00242742338331.issue12254@psf.upfronthosting.co.za>


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

All func_* attributes in 2.x have been given __*__ names in 3.x.

----------
nosy: +eric.araujo
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Jun  3 18:55:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 16:55:25 +0000
Subject: [issue12256] Link isinstance/issubclass doc to abc module
In-Reply-To: <1307120125.95.0.344188720519.issue12256@psf.upfronthosting.co.za>
Message-ID: <1307120125.95.0.344188720519.issue12256@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Doc/library/functions.rst does not talk about how ABC interact with isinstance or issubclass.  This simple patch adds a link.

----------
assignee: eric.araujo
components: Documentation
files: link-isinstance-to-abc.diff
keywords: needs review, patch
messages: 137556
nosy: eric.araujo
priority: normal
severity: normal
stage: patch review
status: open
title: Link isinstance/issubclass doc to abc module
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22235/link-isinstance-to-abc.diff

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

From report at bugs.python.org  Fri Jun  3 19:00:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 17:00:04 +0000
Subject: [issue12223] Datamodel documentation page: 'operator' where 'operand'
	should be
In-Reply-To: <1306834975.07.0.689179229064.issue12223@psf.upfronthosting.co.za>
Message-ID: <1307120404.25.0.873476539321.issue12223@psf.upfronthosting.co.za>


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

Thanks for catching this.  Is this the only instance of the typo, or are there any others in reference/datamodel or library/operator?

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

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

From report at bugs.python.org  Fri Jun  3 19:03:51 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Jun 2011 17:03:51 +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: <1307120631.64.0.554978939948.issue11941@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/issue11941>
_______________________________________

From report at bugs.python.org  Fri Jun  3 19:05:33 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Jun 2011 17:05:33 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1307120733.95.0.087181086654.issue11457@psf.upfronthosting.co.za>


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

The mailbox module would benefit from having this precision available.

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

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

From report at bugs.python.org  Fri Jun  3 19:08:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 17:08:14 +0000
Subject: [issue12257] Use PYPACKAGING_USE_SDK envvar instead of
	DISTUTILS_USE_SDK
In-Reply-To: <1307120894.91.0.571532721021.issue12257@psf.upfronthosting.co.za>
Message-ID: <1307120894.91.0.571532721021.issue12257@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

packaging still uses the DISTUTILS_USE_SDK environment variable to tweak compilation on Windows.  Do we want to change the name?  Pro: separates distutils and packaging, con: requires users to set one more var during the transition period.

I don?t know if MSSdk is distutils-specific (on which case the same question about renaming or not applies) or if it is a Windows envvar used by many tools (in which case packaging can continue to use it too).

----------
assignee: tarek
components: Distutils2
messages: 137559
nosy: alexis, eric.araujo, loewis, tarek
priority: normal
severity: normal
status: open
title: Use PYPACKAGING_USE_SDK envvar instead of DISTUTILS_USE_SDK
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun  3 19:09:01 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Fri, 03 Jun 2011 17:09:01 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1307120941.35.0.144699341364.issue12014@psf.upfronthosting.co.za>


Ben Wolfson <wolfson at gmail.com> added the comment:

Hm. As I interpret this:

    The str.format() function will have
    a minimalist parser which only attempts to figure out when it is
    "done" with an identifier (by finding a '.' or a ']', or '}',
    etc.).

The present implementation is at variance with both the documentation *and* the PEP, since the present implementation does not in fact figure out when it's "done" with an identifier that way. However, this statement is actually a very thin reed on which to make any decisions: a real authority shouldn't say "etc." like that! And, of course, we have to add an implicit "depending on what it's currently looking at" to the parenthetical, because the two strings "{0[a.b]}" and "{0[a].b}" are, and should be, treated differently. In particular, although one could "find" a '.' in the element_index in the former string, the "minimalist parser" should not (and does not) conclude that it's done with the identifier *there*:

>>> "{0[a.b]}".format({"a.b":1})
'1'

Instead it treats the '.' as just another character with no particular syntactic significance, the same way it does 'a' and 'b'. It's a shame that the PEP doesn't go into more detail than it does about this sort of thing.

The same should go for '}', when we're looking at an element_index field. It should be treated as just another character with no particular syntactic significance. At present that is not the case:

>>> "{0[a}b]}".format({"a}b":1})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Missing ']' in format string

If the attached patch were used, the above expression would evaluate to '1' just as did the first one. Now, given the fact that the PEP actually says quite little about how this sort of thing is to be handled, and given (as demonstrated above with the case of the '.' character) that we can't take the little list it gives as indicating when it's done with an identifier regardless of context, I don't think this change would constitute a change *to the specification*; it does, admittedly, constitute an interpretation of the specification, but then, so does the present implementation, and the present implementation is at variance with the PEP *anyway*, as regards the characters ':' and '!'.

The paragraph prior to the one quoted by R. David Murray reads:

    Because keys are not quote-delimited, it is not possible to
    specify arbitrary dictionary keys (e.g., the strings "10" or
    ":-]") from within a format string.

I take it that this means (in the first place) that, because a sequence of digits is interpreted as a number, the following will fail:

'{0[10]}'.format({"10":4})

And indeed it does. The second example is rather unfortunate, though: is the reason one can't use that key because it contains a colon? Or because it contains a right square bracket? Even if the present patch is accepted one couldn't use a right square bracket, since a parser that could figure out where to draw the lines in something like this:

'{0[foo ] bar]}'

would not be very minimalist. However, as I have noted previously, there is no reason to rule out colons and exclamation points in the element_index field. The PEP doesn't actually take up this question in detail. (It hardly does so at all.) However, according to what I think the most reasonable interpretation of the PEP is, the present implementation is at variance with the PEP. The present implementation is certainly at variance with the documentation, which represents to some extent an interpretation and specification of the PEP. 

Consequently, to the extent that changing a specification requires discussion on python-dev, it seems to me that the present implementation is already a de facto change to the specification, while accepting the attached patch would bring the implementation into *greater* accord with the specification---so that (to conclude cheekily) *not* accepting the patch is what should require discussion on python-dev. However, if it is thought necessary, I'll be happy to start the discussion.

----------

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

From report at bugs.python.org  Fri Jun  3 19:14:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 17:14:42 +0000
Subject: [issue12258] Clean up bytes I/O in get_compiler_versions
In-Reply-To: <1307121282.55.0.132082573387.issue12258@psf.upfronthosting.co.za>
Message-ID: <1307121282.55.0.132082573387.issue12258@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

get_compiler_versions uses string regexes to match bytes streams returned by subprocess.  The test did not catch this because they mock subprocess output with strings in self._exes.

We have to decide whether we propagate the bytes object up (and fix two regexes, a comparison and the tests), or to decode the subprocess output to strings.

----------
assignee: tarek
components: Distutils2
messages: 137561
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Clean up bytes I/O in get_compiler_versions
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun  3 19:19:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 17:19:55 +0000
Subject: [issue12259] Test and document which compilers can be created on
	which platform
In-Reply-To: <1307121595.57.0.945178123037.issue12259@psf.upfronthosting.co.za>
Message-ID: <1307121595.57.0.945178123037.issue12259@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

When working on the docs for new_compiler, I read that it was possible to get an msvc compiler on Unix.  I tried it, even wrote a unit test to make sure it worked, and found out that not all compiler classes can be instantiated on my platform.  This should be better documented.

----------
assignee: tarek
components: Distutils2
messages: 137562
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Test and document which compilers can be created on which platform
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun  3 19:24:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 17:24:21 +0000
Subject: [issue12260] Make install default to user site-packages
In-Reply-To: <1307121861.82.0.570588263731.issue12260@psf.upfronthosting.co.za>
Message-ID: <1307121861.82.0.570588263731.issue12260@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Now that we can break compat in distutils2/packaging, we can change the default install dir to use PEP 370 user site-packages.  For users without root, copy-pasting ?pysetup run install_dist? from the docs would Just Work?.  This would also avoid the dreadful advice to use sudo on OSes that have their own package manager and don?t want users to muck up with /usr.

See also #10745.

----------
assignee: tarek
components: Distutils2
messages: 137563
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Make install default to user site-packages
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun  3 19:27:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 03 Jun 2011 17:27:36 +0000
Subject: =?utf-8?q?=5Bissue12249=5D_Document_working_dir_for_=E2=80=9Cmake_html?=
	=?utf-8?b?4oCd?=
In-Reply-To: <1307059685.23.0.0593360384194.issue12249@psf.upfronthosting.co.za>
Message-ID: <E1QSY9n-00048S-08@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 4efc9ded0a03 by ?ric Araujo in branch '3.2':
Document working dir for ?make html? (#12249).  Patch by Tshepang Lekhonkhobe.
http://hg.python.org/cpython/rev/4efc9ded0a03

New changeset 41c918897286 by ?ric Araujo in branch 'default':
Merge #12249 fix from 3.2
http://hg.python.org/cpython/rev/41c918897286

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

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

From report at bugs.python.org  Fri Jun  3 19:31:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 03 Jun 2011 17:31:00 +0000
Subject: =?utf-8?q?=5Bissue12249=5D_Document_working_dir_for_=E2=80=9Cmake_html?=
	=?utf-8?b?4oCd?=
In-Reply-To: <1307059685.23.0.0593360384194.issue12249@psf.upfronthosting.co.za>
Message-ID: <E1QSYD4-0004QP-UJ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 39c29bc8bc35 by ?ric Araujo in branch '2.7':
Document working dir for ?make html? (#12249).  Patch by Tshepang Lekhonkhobe.
http://hg.python.org/cpython/rev/39c29bc8bc35

----------

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

From report at bugs.python.org  Fri Jun  3 19:32:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Jun 2011 17:32:09 +0000
Subject: =?utf-8?q?=5Bissue12249=5D_Document_working_dir_for_=E2=80=9Cmake_html?=
	=?utf-8?b?4oCd?=
In-Reply-To: <1307059685.23.0.0593360384194.issue12249@psf.upfronthosting.co.za>
Message-ID: <1307122329.91.0.0563908143922.issue12249@psf.upfronthosting.co.za>


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

Thank you for the report and patch!

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

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

From report at bugs.python.org  Fri Jun  3 19:41:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Jun 2011 17:41:17 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1307122877.46.0.696455719004.issue12014@psf.upfronthosting.co.za>


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

I agree that the current situation is a bit murky and ought to be clarified, but I'm going to leave it to Eric to point they way forward, as he is far more knowledgeable about this area than I.

----------

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

From report at bugs.python.org  Fri Jun  3 20:03:04 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 03 Jun 2011 18:03:04 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307124184.34.0.403914134439.issue12248@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/issue12248>
_______________________________________

From report at bugs.python.org  Fri Jun  3 20:25:22 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 03 Jun 2011 18:25:22 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1307122877.46.0.696455719004.issue12014@psf.upfronthosting.co.za>
Message-ID: <20110603182518.GA1767@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

I've played around with the str.format() code for a few weeks now, to
investigate its poor performance compared to the % operator.

Having written a few parsers before, I would change it to parse each
part separately:

1. field_name
2a. if followed by '[': element_index (anything until ']')
2b. elif followed by '.': attribute_name
3. if followed by '!': conversion
4. if followed by '}': format_spec (anything until '}')

It seems to me that the documentation also suggests this behavior, and
that this bug report is correct.

What comes to parsing identifiers, it seems to me that stopping at
'.', ']', and '}' is not enough. In field_name, '[', ':' and '!' would
also be needed, and ':' and '!' in attribute_name. It's a shame that
PEP3101 is so vague on this subject.

----------

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

From report at bugs.python.org  Fri Jun  3 20:39:04 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Jun 2011 18:39:04 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1307126344.9.0.702994262294.issue12226@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I think there should be a warning that the connection is unauthenticated
(i.e. not secure). Users tend to be upset if they see 'https' and later
find out that no certificates were verified.


A reasonably secure alternative is to publish the pypi server
certificate in a couple of places (python-dev, www.python.org).
Then the user can import the certificate into the browser while
on a trusted connection and henceforth do all uploading etc.
via the browser.

----------

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

From report at bugs.python.org  Fri Jun  3 20:56:39 2011
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 03 Jun 2011 18:56:39 +0000
Subject: [issue12246] create installation path if it's non-existent
In-Reply-To: <1307117938.37.0.93511317422.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307127372.17643.1.camel@debian>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

On Fri, 2011-06-03 at 16:18 +0000, ?ric Araujo wrote:
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> Ah, I understand; I have a $srcdir/Lib/site-packages directory, but packaging wants to install into $prefix/site-packages, which does not exist.  +1 to adding a nice message.  Tshepang, would you like to update your patch?

Why not just create the directory, instead of print the warning? Is
there any harm?

----------

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

From report at bugs.python.org  Fri Jun  3 20:59:22 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 03 Jun 2011 18:59:22 +0000
Subject: [issue11583] os.path.isdir() is slow on windows
In-Reply-To: <1300354713.42.0.570312056806.issue11583@psf.upfronthosting.co.za>
Message-ID: <1307127562.65.0.465732341276.issue11583@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Attached is a patch that makes this about twice as fast for regular files and about 15 times faster for symbolic links and directories.

Not that this would be anyone's performance bottleneck, but it does make the time more of a constant due to the recursion and extra overhead when stat'ing symbolic paths. The numbers were tested with the patch on #12084 (new stat impl).


# The numbers were run before I hooked nt._isdir up through Lib/ntpath.py, so os.path.isdir is the old way.
# Regular file
>PCbuild\amd64\python.exe -m timeit -s "import nt" "nt._isdir('README')"
10000 loops, best of 3: 25 usec per loop

>PCbuild\amd64\python.exe -m timeit -s "import os" "os.path.isdir('README')"
10000 loops, best of 3: 43 usec per loop

# Regular directory

>PCbuild\amd64\python.exe -m timeit -s "import nt" "nt._isdir('Lib')"
10000 loops, best of 3: 24.3 usec per loop

>PCbuild\amd64\python.exe -m timeit -s "import os" "os.path.isdir('Lib')"
10000 loops, best of 3: 41.4 usec per loop

# testlink is a symbolically linked directory

>PCbuild\amd64\python.exe -m timeit -s "import nt" "nt._isdir('testlink')"
10000 loops, best of 3: 26.1 usec per loop

>PCbuild\amd64\python.exe -m timeit -s "import os" "os.path.isdir('testlink')"
1000 loops, best of 3: 415 usec per loop

# setup.py.link is a symbolic link

>PCbuild\amd64\python.exe -m timeit -s "import nt" "nt._isdir('setup.py.link')"
10000 loops, best of 3: 25.8 usec per loop

>PCbuild\amd64\python.exe -m timeit -s "import os" "os.path.isdir('setup.py.link')"
1000 loops, best of 3: 336 usec per loop

----------
keywords: +needs review, patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file22236/issue11583.diff

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

From report at bugs.python.org  Fri Jun  3 21:08:34 2011
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 03 Jun 2011 19:08:34 +0000
Subject: [issue12249] add missing command
In-Reply-To: <1307116072.0.0.51026958669.issue12249@psf.upfronthosting.co.za>
Message-ID: <1307128087.17643.3.camel@debian>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

On Fri, 2011-06-03 at 15:47 +0000, ?ric Araujo wrote:
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> Your patch adds the cd before running make, but other examples and filenames (for example :file:`tools/sphinx`) are also relative to Doc.  How about adding something like this after the very first paragraph:
> 
> All commands in this document should be run from the :file:`Doc` directory of a Python checkout; all file and directory names are also relative to :file:`Doc`.

I actually much prefer your alternative. When I prepared the patch, I
didn't take note that the rest of the page's content assumed that one
should be in that directory.

----------
title: Document working dir for ?make html? -> add missing command

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

From report at bugs.python.org  Fri Jun  3 21:20:43 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 03 Jun 2011 19:20:43 +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: <1307128843.4.0.255174862099.issue11941@psf.upfronthosting.co.za>


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

Attached is a patch for review.

It adds st_atim, st_ctim and st_mtim.

They are defined even when the underlying system does not have nanosecond precision.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file22237/issue11941.patch

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

From report at bugs.python.org  Fri Jun  3 21:34:56 2011
From: report at bugs.python.org (Tim Lesher)
Date: Fri, 03 Jun 2011 19:34:56 +0000
Subject: [issue12261] urllib.parse docs still refer to urlparse
In-Reply-To: <1307129696.46.0.265723026729.issue12261@psf.upfronthosting.co.za>
Message-ID: <1307129696.46.0.265723026729.issue12261@psf.upfronthosting.co.za>


New submission from Tim Lesher <tlesher at gmail.com>:

While most of the occurrences of "urlparse" were corrected to "urllib.parse" when the module was renamed, two were missed: one in the second example, and one in the "See also" note for RFC 3986.

----------
assignee: docs at python
components: Documentation
messages: 137574
nosy: docs at python, tlesher
priority: normal
severity: normal
status: open
title: urllib.parse docs still refer to urlparse
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Jun  3 21:36:40 2011
From: report at bugs.python.org (Tim Lesher)
Date: Fri, 03 Jun 2011 19:36:40 +0000
Subject: [issue12261] urllib.parse docs still refer to urlparse
In-Reply-To: <1307129696.46.0.265723026729.issue12261@psf.upfronthosting.co.za>
Message-ID: <1307129800.78.0.495063004804.issue12261@psf.upfronthosting.co.za>


Changes by Tim Lesher <tlesher at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22238/remove-urlparse.patch

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

From report at bugs.python.org  Fri Jun  3 21:47:06 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 03 Jun 2011 19:47:06 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1307130426.8.0.784076791002.issue12226@psf.upfronthosting.co.za>


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

If users use a browser to do secure uploading, there is no need to publish the certificate. It is signed by a trusted CA (cacert), so you just need to make sure your browser knows about the cacert certificate.

----------

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

From report at bugs.python.org  Fri Jun  3 21:47:49 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 03 Jun 2011 19:47:49 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1307130469.16.0.861092248507.issue12014@psf.upfronthosting.co.za>


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

PEP 3101 defines format strings as intermingled character data and markup. Markup defines replacement fields and is delimited by braces. Only after markup is extracted does the PEP talk about interpreting the contents of the markup.

So, given "{0[a}b]}" the parser first parses out the character data and the markup. The first piece of markup is "{0[a}". That gives a syntax error because it's missing a right bracket.

I realize you'd like the parser to find the markup as the entire string, but that's not how I read the PEP.

----------

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

From report at bugs.python.org  Fri Jun  3 21:54:21 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 03 Jun 2011 19:54:21 +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: <1307130861.47.0.926853780316.issue11941@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

st_atim, st_mtim and st_ctim were introduced in 2008 version of POSIX (and were earlier provided by glibc as an extension). To avoid compilation failure with some exotic versions of libc, I suggest:
- In configure.in:
AC_CHECK_MEMBERS([struct stat.st_atim])
AC_CHECK_MEMBERS([struct stat.st_ctim])
AC_CHECK_MEMBERS([struct stat.st_mtim])
- In Modules/posixmodule.c:
    PyObject *atim = Py_BuildValue(_STAT_FMT,
                            st->st_atime,
#ifdef HAVE_STRUCT_STAT_ST_ATIM
                            st->st_atim.tv_nsec
#else
                            0
#endif
                            );
...

----------

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

From report at bugs.python.org  Fri Jun  3 21:57:51 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 03 Jun 2011 19:57:51 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1307131071.91.0.794356823268.issue11457@psf.upfronthosting.co.za>


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

I suggest that rather than using composite time stamps, decimal.Decimal is used to represent high-precision time in Python.

On input to os.utime, the function could just polymorphically accept Decimal, and try its best.

I see three approaches that preserve compatibility for stat (plus the incompatible one of just changing the field types of struct stat):
1. have a flag in the stat module to change the field types globally.
   This would be appropriate if the ultimate goal is to eventually change
   the fields in an incompatible way in Python 4.
2. have a flag to stat that changes the field types, on a per-call basis
3. mirror the existing fields, into _decimal versions.

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

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

From report at bugs.python.org  Fri Jun  3 22:03:34 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 03 Jun 2011 20:03:34 +0000
Subject: [issue11583] os.path.isdir() is slow on windows
In-Reply-To: <1300354713.42.0.570312056806.issue11583@psf.upfronthosting.co.za>
Message-ID: <1307131414.16.0.682944625036.issue11583@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Looks like I didn't test this enough - many other test failures are occurring. Disregard this patch for now.

----------

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

From report at bugs.python.org  Fri Jun  3 22:11:11 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 03 Jun 2011 20:11:11 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1307131871.71.0.137541188974.issue11457@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

os.utimensat() and os.futimens() already exist since Python 3.3 and require 2-tuples (or None) as second and third argument.

(utime() is deprecated since POSIX 2008: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/utime.h.html)

(Changes specific to os.stat() are discussed in issue #11941.)

----------

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

From report at bugs.python.org  Fri Jun  3 22:11:43 2011
From: report at bugs.python.org (Tim Golden)
Date: Fri, 03 Jun 2011 20:11:43 +0000
Subject: [issue11583] os.path.isdir() is slow on windows
In-Reply-To: <1300354713.42.0.570312056806.issue11583@psf.upfronthosting.co.za>
Message-ID: <1307131903.75.0.688450723753.issue11583@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

One (presumably unintended) side-effect is that you can now do os.path.isdir on a wildcard and the first returned entry will be tested for directoryness:

import os
os.path.isdir ("c:/tem*")
# => True where c:/temp exists

----------

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

From report at bugs.python.org  Fri Jun  3 22:14:52 2011
From: report at bugs.python.org (Tim Lesher)
Date: Fri, 03 Jun 2011 20:14:52 +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: <1307132092.02.0.793336564665.issue11620@psf.upfronthosting.co.za>


Changes by Tim Lesher <tlesher at gmail.com>:


----------
nosy: +tlesher

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

From report at bugs.python.org  Fri Jun  3 22:35:48 2011
From: report at bugs.python.org (Jesse Litton)
Date: Fri, 03 Jun 2011 20:35:48 +0000
Subject: [issue12262] Not Inheriting File Descriptors on Windows?
In-Reply-To: <1307133348.7.0.486629796214.issue12262@psf.upfronthosting.co.za>
Message-ID: <1307133348.7.0.486629796214.issue12262@psf.upfronthosting.co.za>


New submission from Jesse Litton <3vi1jl at gmail.com>:

On Windows, I've been trying to call a test script that gets its I/O handled via file descriptors 3 & 4 

  socat EXEC:"python test.py userid",pty,fdin=3,fdout=4 TCP4:server:23,crlf

But I'm getting "[Errno 9] Bad file descriptor" when the python script attempts to os.fdopen(3, 'r').

I've tried just piping an echo's output redirected (3<&1 I think... though I might have that backwards as I've tried it every conceivable way) into the script, but I always get the bad file descriptor error.

I can create a pipe() in the program I can get an actual FD 3 & 4... but they seem to have no relation to the FD's that were set up by the invoking command-line/script.

I'm new to Python - is there something simple I'm overlooking, or is this a known bug that I just haven't been able to find in my last few hours of web searches?  I can't believe I would be the only one doing this type of redirection on Windows.

Thanks in advance for any guidance/resolution you can offer.

----------
components: Interpreter Core
messages: 137582
nosy: 3vi1
priority: normal
severity: normal
status: open
title: Not Inheriting File Descriptors on Windows?
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri Jun  3 22:37:02 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 03 Jun 2011 20:37:02 +0000
Subject: [issue12262] Not Inheriting File Descriptors on Windows?
In-Reply-To: <1307133348.7.0.486629796214.issue12262@psf.upfronthosting.co.za>
Message-ID: <1307133422.08.0.165707062374.issue12262@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Can you provide a simple test script?

----------
nosy: +brian.curtin

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

From report at bugs.python.org  Fri Jun  3 22:52:44 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 03 Jun 2011 20:52:44 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1307134364.91.0.937648462344.issue12226@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Sorry for the delay. I've just uploaded http://pypi.python.org/pypi/ctypesgen/0.r125 from Ubuntu using python2.6 with patched distutils module to https://pypi.python.org/pypi and can confirm it works without problems on Linux.

So I can guarantee there won't be any regress in 99.9% of cases and <0.1% of cases that are left, risk of breaking these flaky setups doesn't outweight the need to close this security hole.

I can fill separate bug for packaging, server certificate validation and support for non-SSL builds of python (for which there is workaround with upload -r <server> option that I've just discovered), but it is an additional delay and the only reason I invested some time into this issue is because I saw RC announcements.


P.S. To Martin. CAcert is not trusted authority on Windows, and all browsers warn about it, so we need to distribute its root certificate with Python if we want to validate ours.

----------

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

From report at bugs.python.org  Fri Jun  3 22:55:52 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 03 Jun 2011 20:55:52 +0000
Subject: [issue11583] os.path.isdir() is slow on windows
In-Reply-To: <1300354713.42.0.570312056806.issue11583@psf.upfronthosting.co.za>
Message-ID: <1307134552.3.0.102969055662.issue11583@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Here's a patch that works. All tests are passing.

I changed from using FindFirstFile to GetFileAttributes, which provides basically the same performance characteristics.

One change in this implementation is to not raise a WindowsError when the file cannot be opened. The original os.stat would return False in that case, so now this function returns False (before it just passed on the WindowsError, which killed lots of tests).

----------
Added file: http://bugs.python.org/file22239/issue11583_v2.diff

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

From report at bugs.python.org  Fri Jun  3 22:56:57 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 03 Jun 2011 20:56:57 +0000
Subject: [issue12262] Not Inheriting File Descriptors on Windows?
In-Reply-To: <1307133348.7.0.486629796214.issue12262@psf.upfronthosting.co.za>
Message-ID: <1307134617.44.0.770350694508.issue12262@psf.upfronthosting.co.za>


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

Is "socat" a cygwin utility?  In this case, you should use the python interpreter built for the cygwin platform.

I'm quite certain that the standard win32 python cannot work the way you want.  Keep in mind that on Windows, file descriptors are emulated; only HANDLEs are really inherited between processes.  And I know that the Microsoft C run-time only initializes file descriptors 0, 1 and 2 from the three standard handles.

The cygwin compatibility layer certainly does it differently and uses other ways to pass file descriptors between processes.

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

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

From report at bugs.python.org  Fri Jun  3 22:57:48 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Jun 2011 20:57:48 +0000
Subject: [issue12198] zipfile.py:1047: DeprecationWarning: 'H' format requires
	0 <= number <= 65535
In-Reply-To: <1306521866.64.0.0795641748962.issue12198@psf.upfronthosting.co.za>
Message-ID: <1307134668.19.0.944476054059.issue12198@psf.upfronthosting.co.za>


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


----------
nosy: +alanmcintyre
versions: +Python 2.7 -Python 2.6

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

From report at bugs.python.org  Fri Jun  3 22:58:56 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Jun 2011 20:58:56 +0000
Subject: [issue12201] Returning FILETIME is unsupported in
	msilib.SummaryInformation.GetProperty()
In-Reply-To: <1306590826.19.0.496191579279.issue12201@psf.upfronthosting.co.za>
Message-ID: <1307134736.22.0.282264365172.issue12201@psf.upfronthosting.co.za>


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


----------
type:  -> feature request
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Fri Jun  3 23:03:03 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 03 Jun 2011 21:03:03 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307134983.1.0.68986979723.issue12248@psf.upfronthosting.co.za>


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

No additional type-checking was added. The problem is that __dir__ didn't work on old-style classes at all in 2.7.1:

$ python
Python 2.7.1 (r271:86832, Mar 24 2011, 22:44:47)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo:
... def __dir__(self):
... return ['a', 'b', 'c']
...
>>> class Bar:
... def __dir__(self):
... return ('a', 'b', 'c')
...
>>> print dir(Foo())
['__dir__', '__doc__', '__module__']
>>> print dir(Bar())
['__dir__', '__doc__', '__module__']

Loosening type-checks on dir() is fine with me but is really a 3.3 issue.

----------

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

From report at bugs.python.org  Fri Jun  3 23:08:42 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Fri, 03 Jun 2011 21:08:42 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1307135322.66.0.0230849647886.issue12014@psf.upfronthosting.co.za>


Ben Wolfson <wolfson at gmail.com> added the comment:

"""
PEP 3101 defines format strings as intermingled character data and markup. Markup defines replacement fields and is delimited by braces. Only after markup is extracted does the PEP talk about interpreting the contents of the markup.

So, given "{0[a}b]}" the parser first parses out the character data and the markup. The first piece of markup is "{0[a}". That gives a syntax error because it's missing a right bracket.
"""

The intermingling of character data and markup is irrelevant; character data is defined as "data which is transferred unchanged from the format string to the output string", and nothing in "{0[a]}" is transferred unchanged.

Two parts of the PEP suggest that the markup in the above should be "{0[a}" rather than "{0[a}]}":

    Brace characters ('curly braces') are used to indicate a
    replacement field within the string:

    [...]

    Braces can be escaped by doubling:

and

    Note that the doubled '}' at the end, which would normally be
    escaped, is not escaped in this case.  The reason is because
    the '{{' and '}}' syntax for escapes is only applied when used
    *outside* of a format field.  Within a format field, the brace
    characters always have their normal meaning.

The first statement obviously doesn't mean that the exclusive use of braces in a format string is to indicate replacement fields, since it's immediately acknowledged that sometimes braces can occur without indicating a replacement field, when they're escaped. The second occurs specifically in the context of talking about escaping braces, so the following interpretation remains available: within a format field, a brace is a brace is a brace---that is, a pair of braces is a pair of braces, not an escape for a single brace.

In fact, though the following argument may appear Jesuitical, it does, I think, hold water: The second quotation above mentions braces within a *format field*. What is a format field? Well, we know that "The element with the braces is called a 'field'", but "format field" is more specific; the whole thing between braces isn't (necessarily!) the format field. And we know that

    Fields consist
    of a 'field name', which can either be simple or compound, and an
    optional 'format specifier'.

So, perhaps a format field is the part of the broader field where the format specifier lives. And lo, it's in the part of the PEP talking about "Format Specifiers" that we get the second quotation above.

    Each field can also specify an optional set of 'format
    specifiers' which can be used to adjust the format of that field.
    Format specifiers follow the field name, with a colon (':')
    character separating the two:

So even if you think that the claim that "within a format field, the brace characters always have their normal meaning" means not "the brace characters aren't escaped" but "the brace characters indicate a replacement field", that statement could just mean that they only have this significance in *part* of the *replacement* field---the part having to do with the formatting of the replacement text---and not the whole replacement field. So that, for instance, the following does what you'd expect:


>>> "{0[{4}]}".format({"{4}":3})
'3'

And it *does* do what you'd expect, in the *current* implementation---that is, the braces here don't have the meaning of introducing a replacement field [they're kinda-sorta parsed as if they were introduced a replacement field but that is obviously not their semantics], but are instead just treated as braces. They also aren't escaped: 

>>> "{0[{{4}}]}".format({"{{4}}":3})
'3'

----------

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

From report at bugs.python.org  Fri Jun  3 23:13:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jun 2011 21:13:36 +0000
Subject: [issue12231] regrtest: add -k and -K options to filter tests by
	function/file names
In-Reply-To: <1306886173.49.0.536773734975.issue12231@psf.upfronthosting.co.za>
Message-ID: <1307135616.9.0.0396342935564.issue12231@psf.upfronthosting.co.za>


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

> How about reusing unittest discovery in regrtest?

Does this feature support filtering by keyword for file names and function names?

----------

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

From report at bugs.python.org  Fri Jun  3 23:30:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Jun 2011 21:30:24 +0000
Subject: [issue12207] Document ast.PyCF_ONLY_AST
In-Reply-To: <1306689830.34.0.885575322408.issue12207@psf.upfronthosting.co.za>
Message-ID: <1307136624.92.0.714910735079.issue12207@psf.upfronthosting.co.za>


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

This is a bit tricky. It may be superseded, but it is still there, is possible used in older code, has not been deprecated as far as I know, and appears in dir(ast).

The two current mentions of PyCF_ONLY_AST in ast doc are:

"An abstract syntax tree can be generated by passing ast.PyCF_ONLY_AST as a flag to the compile() built-in function, or using the parse() helper provided in this module." (near the top )

"ast.parse(source, filename='<unknown>', mode='exec') 
Parse the source into an AST node. Equivalent to compile(source, filename, mode, ast.PyCF_ONLY_AST)."

The first mention is referred to in the compile entry:

"compile(source, filename, mode, flags=0, dont_inherit=False, optimize=-1) 
Compile the source into a code or AST object. Code objects can be executed by exec() or eval(). source can either be a string or an AST object. Refer to the ast module documentation for information on how to work with AST objects."

In my view, it is adequately documented now, should not be undocumented, and should not be given more prominence either. So I recommend closing this.

Hmm. It should be indexed for anyone reading existing code. If possible, I would have the index point to the first current sentence, which also mentions .parse() as an alternative.

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

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

From report at bugs.python.org  Fri Jun  3 23:38:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 03 Jun 2011 21:38:16 +0000
Subject: [issue12016] Wrong behavior for '\xff\n'.decode('gb2312', 'ignore')
In-Reply-To: <1304673377.35.0.784853339325.issue12016@psf.upfronthosting.co.za>
Message-ID: <E1QSc4N-0006xl-6Z@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3610841f7357 by Victor Stinner in branch '3.2':
Issue #12016: Reindent decoders of HK and JP codecs
http://hg.python.org/cpython/rev/3610841f7357

New changeset aa07c1237f4e by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12016: Reindent decoders of HK and JP codecs
http://hg.python.org/cpython/rev/aa07c1237f4e

New changeset 685351d65592 by Victor Stinner in branch '2.7':
Issue #12016: Reindent decoders of HK and JP codecs
http://hg.python.org/cpython/rev/685351d65592

----------

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

From report at bugs.python.org  Fri Jun  3 23:42:59 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Jun 2011 21:42:59 +0000
Subject: [issue12211] math.copysign must keep object type.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1307137379.38.0.417425185016.issue12211@psf.upfronthosting.co.za>


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

As with all the math docs, 'x' refers to the value, not the object with the value. However, "Return abs(x) with the sign of y" is, to me, clearer and more accurate. Both doc string and doc chapter should get any modification.

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

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

From report at bugs.python.org  Fri Jun  3 23:50:01 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Jun 2011 21:50:01 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1307131071.91.0.794356823268.issue11457@psf.upfronthosting.co.za>
Message-ID: <BANLkTiky8Hf03gVEuFy-v-cAg0K92sPVTQ@mail.gmail.com>


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

On Fri, Jun 3, 2011 at 3:57 PM, Martin v. L?wis <report at bugs.python.org> wrote:
..
> I suggest that rather than using composite time stamps, decimal.Decimal is used to represent high-precision time in Python.

I support this idea in theory, but as long as decimal is implemented
in Python, os module should probably expose a low level (tuple-based?)
interface and a higher level module would provide Decimal-based
high-precision time.

BTW, what is the status of cdecimal?

----------

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

From report at bugs.python.org  Fri Jun  3 23:56:58 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 03 Jun 2011 21:56:58 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1307138218.86.0.164230865457.issue12014@psf.upfronthosting.co.za>


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

The intermingling of character data and markup is far from irrelevant: that's exactly what str.format() does! I don't see how it can be irrelevant to a discussion of how the string is parsed.

Note that there are no restrictions, in general, on what's in a format specifier. Braces can be in format specifiers, if they make sense for that type. For example:

>>> from datetime import datetime
>>> format(datetime.now(), '{}%Y-%m-%d}{')
'{}2011-06-03}{'

It's definitely true that you can have valid format specifiers that cannot be represented in strings parsed by str.format(). The PEP talks about both format specifiers in the abstract (stand alone) and format specifiers contained in str.format() strings.

The current implementation of str.format() finds matched pairs of braces and call what's inside "markup", then parse that markup. This indeed restricts what's inside the markup. I believe the implementation is compliant with the PEP.

It's also true that other interpretations of the PEP are possible. I'm just not sure the benefit to be gained justifies changing all of the extant str.format() implementations, in addition to explaining the different behavior.

Many useful features for str.format() were rejected in order to keep the implementation and documentation simple.

I'm not saying change and improvement is impossible. I'm just not convinced it's worthwhile.

----------

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

From report at bugs.python.org  Fri Jun  3 23:58:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 03 Jun 2011 21:58:06 +0000
Subject: [issue12016] Wrong behavior for '\xff\n'.decode('gb2312', 'ignore')
In-Reply-To: <1304673377.35.0.784853339325.issue12016@psf.upfronthosting.co.za>
Message-ID: <E1QScNZ-0008Rl-8K@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8572bf1b56ec by Victor Stinner in branch '3.2':
Issue #12016: Add test_errorhandle() to TestBase_Mapping of
http://hg.python.org/cpython/rev/8572bf1b56ec

New changeset c3dc94d53ef8 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12016: Add test_errorhandle() to TestBase_Mapping of
http://hg.python.org/cpython/rev/c3dc94d53ef8

New changeset 53912b58eee6 by Victor Stinner in branch '2.7':
Issue #12016: Add test_errorhandle() to TestBase_Mapping of
http://hg.python.org/cpython/rev/53912b58eee6

----------

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

From report at bugs.python.org  Sat Jun  4 00:00:05 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Jun 2011 22:00:05 +0000
Subject: [issue12215] TextIOWrapper: issues with interlaced read-write
In-Reply-To: <1306759084.05.0.928785750761.issue12215@psf.upfronthosting.co.za>
Message-ID: <1307138405.77.0.642765703636.issue12215@psf.upfronthosting.co.za>


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

For c stdio files, intermixed reads and writes require a file positioning operation. This is a nuisance and source of program bugs. I do not see any such limitation documented for our io module. So for both reasons, it will be nice to not have the limitation in the code.

If I understand, the essence of the patch is to do the file positioning automatically internally when needed.

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

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

From report at bugs.python.org  Sat Jun  4 00:02:35 2011
From: report at bugs.python.org (Ashley Anderson)
Date: Fri, 03 Jun 2011 22:02:35 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1307138555.08.0.890632921897.issue12006@psf.upfronthosting.co.za>


Ashley Anderson <aganders3 at gmail.com> added the comment:

Attaching a patch for the documentation just in time for the weekend!

----------
Added file: http://bugs.python.org/file22240/12006_doc.patch

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

From report at bugs.python.org  Sat Jun  4 00:02:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jun 2011 22:02:40 +0000
Subject: [issue12215] TextIOWrapper: issues with interlaced read-write
In-Reply-To: <1306759084.05.0.928785750761.issue12215@psf.upfronthosting.co.za>
Message-ID: <1307138560.64.0.602965151031.issue12215@psf.upfronthosting.co.za>


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

> If I understand, the essence of the patch is to do
> the file positioning automatically internally when needed.

My patch is just a proposition to fix the issue. I wrote "I suppose that we can do better": self.seek(self.tell()) is more a workaround than a real fix. I don't understand why it does fix this bug :-)

----------

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

From report at bugs.python.org  Sat Jun  4 00:11:13 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 03 Jun 2011 22:11:13 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307139073.13.0.332246988403.issue12248@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/issue12248>
_______________________________________

From report at bugs.python.org  Sat Jun  4 00:12:25 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 03 Jun 2011 22:12:25 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1307131871.71.0.137541188974.issue11457@psf.upfronthosting.co.za>
Message-ID: <4DE95C47.4050600@v.loewis.de>


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

Am 03.06.2011 22:11, schrieb Arfrever Frehtes Taifersar Arahesis:
> 
> Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:
> 
> os.utimensat() and os.futimens() already exist since Python 3.3 and require 2-tuples (or None) as second and third argument.

"Already since 3.3" means "they don't exist yet". I.e. it isn't too late
to change them.

> (utime() is deprecated since POSIX 2008: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/utime.h.html)

This is a case where I think Python shouldn't follow POSIX deprecation.
In C, you need to change the function name to change the parameter
types; not so in Python.

----------

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

From report at bugs.python.org  Sat Jun  4 00:13:15 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 03 Jun 2011 22:13:15 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <BANLkTiky8Hf03gVEuFy-v-cAg0K92sPVTQ@mail.gmail.com>
Message-ID: <4DE95C79.8080600@v.loewis.de>


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

> I support this idea in theory, but as long as decimal is implemented
> in Python, os module should probably expose a low level (tuple-based?)
> interface and a higher level module would provide Decimal-based
> high-precision time.

Can you explain why you think so? I fail to see the connection.

----------

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

From report at bugs.python.org  Sat Jun  4 00:17:16 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Fri, 03 Jun 2011 22:17:16 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1307139436.39.0.472744217827.issue12014@psf.upfronthosting.co.za>


Ben Wolfson <wolfson at gmail.com> added the comment:

str.format doesn't intermingle character data and markup. The PEP is quite clear about the terms in this case, at least: the *argument* to str.format consists of character data (passed through unchanged) and markup (processed). That's what it means to say that "Character data is data which is transferred unchanged from the format string to the output string". In "My name is {0}", "My name is " is transferred unchanged from the format string to the output string when the string is formatted. We're talking about how the *markup* is defined.

"""
The current implementation of str.format() finds matched pairs of braces and call what's inside "markup", then parse that markup.
"""

This is false, as I demonstrated.

>>> d = {"{0}": "spam"}
>>> # a matched pair of braces. What's inside is considered markup.
... 
>>> "{0}".format(d)
"{'{0}': 'spam'}"
>>> # a matched pair of braces. Inside is a matched pair of braces, and what's inside of that is not considered markup.
... 
>>> "{0[{0}]}".format(d)
'spam'
>>> 

"""
It's also true that other interpretations of the PEP are possible. I'm just not sure the benefit to be gained justifies changing all of the extant str.format() implementations, in addition to explaining the different behavior.
"""

Well, the beauty of it is, you wouldn't have to explain the different behavior, because the patch makes it the case that the explanation already in the documentation is correct. It is currently not correct. That's why I found out about this current state of affairs: I read the documentation's explanation and believed it, and only after digging into the code did I understand the actual behavior.

It is also not a difficult change to make, would be backwards-compatible (anyway I rather doubt anyone was relying on a "{0[:]}".format(whatever) raising an exception [1]), and relaxes a restriction that is not well motivated by the text of the PEP, is not consistently applied in the implementation (see above), and is confusing and limits the usefulness of the format method. It is true that I don't know where else, beyond the implementation in string_format.h, modifications would need to be made, but I'd be willing to undertake the task.

[1] and given that the present implementation does that, it's already noncompliant with the PEP, regardless of what one makes of curly braces.

----------

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

From report at bugs.python.org  Sat Jun  4 00:20:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jun 2011 22:20:04 +0000
Subject: [issue12016] Wrong behavior for '\xff\n'.decode('gb2312', 'ignore')
In-Reply-To: <1304673377.35.0.784853339325.issue12016@psf.upfronthosting.co.za>
Message-ID: <1307139604.35.0.517194006092.issue12016@psf.upfronthosting.co.za>


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

cjk_decode.patch:
 - patch *all* CJK decoders to replace only the first byte of an invalid byte sequence (by U+FFFD). Example from the issue title: b'\xff\n'.decode('gb2312', 'replace') gives now '?\n' instead of just '?'
 - add at least one unit test for *each* path in the decoder (sometimes it was really hard to see how to go into a specific path, especially for the johab decoder!)
 - add testcases for euc_jis_2004 and shift_jis_2004
 - factorize "codec tests" (codectests) of all japanese EUC tests (euc_commontests)

Because I consider this issue as a bug, I would like to apply this patch to 2.7, 3.2 and 3.3.

----------
keywords: +patch
Added file: http://bugs.python.org/file22241/cjk_decode.patch

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

From report at bugs.python.org  Sat Jun  4 00:20:11 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 03 Jun 2011 22:20:11 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1307139611.94.0.64444448227.issue12014@psf.upfronthosting.co.za>


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

>From the PEP: "Format strings consist of intermingled character data and markup."

----------

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

From report at bugs.python.org  Sat Jun  4 00:33:58 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Jun 2011 22:33:58 +0000
Subject: [issue12219] tkinter.filedialog.askopenfilename XT dialog on Windows 7
In-Reply-To: <1306788881.55.0.171400893605.issue12219@psf.upfronthosting.co.za>
Message-ID: <1307140438.07.0.383095975164.issue12219@psf.upfronthosting.co.za>


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

I have no idea what 'XT' in the title means.

The only possible relevant change I *know* of is that 3.2 on Windows comes with a later version tk/tcl 8.5 than 3.1. If you find the exact version numbers, you could query/report on the tk/tcl forums, also at ActiveState.

You could also diff the 3.1 and 3.2 versions of the relevant tkinter files, (particularly filedialog, commondialog, dialog) working back from tkinter.filedialog.askopenfilename, and see if there were any possibly relevant changes on our side.

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

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

From report at bugs.python.org  Sat Jun  4 00:34:46 2011
From: report at bugs.python.org (Erik Bray)
Date: Fri, 03 Jun 2011 22:34:46 +0000
Subject: [issue12240] Allow multiple setup_hooks
In-Reply-To: <1307026779.27.0.653754848212.issue12240@psf.upfronthosting.co.za>
Message-ID: <1307140486.78.0.462706691983.issue12240@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

Great!  I'll add a patch shortly.

----------

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

From report at bugs.python.org  Sat Jun  4 00:37:09 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Jun 2011 22:37:09 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <4DE95C79.8080600@v.loewis.de>
Message-ID: <BANLkTim9t9edZZ3+Fkh+KPXs4Bvc8=dKMA@mail.gmail.com>


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

On Fri, Jun 3, 2011 at 6:13 PM, Martin v. L?wis <report at bugs.python.org> wrote:
..
>> I support this idea in theory, but as long as decimal is implemented
>> in Python, os module should probably expose a low level (tuple-based?)
>> interface and a higher level module would provide Decimal-based
>> high-precision time.
>
> Can you explain why you think so? I fail to see the connection.

One reason is the desire to avoid loading Python module from a
C-module.  I understand that this ship has already left the port with
larger and larger portions of stdlib being implemented in Python, but
doing that in a basic module such as os (or rather posix) is likely to
cause more problems than what we have in other similar situation.  For
example, strptime is implemented in a Python module loaded by time and
datetime implemented in C.  This works, but at a cost of extreme
trickery in the test suit and similar problems encountered by
sophisticated applications.  As far as I remember, some multi-threding
issues have never been resolved.

----------

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

From report at bugs.python.org  Sat Jun  4 00:52:05 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 03 Jun 2011 22:52:05 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1307141525.34.0.40216674519.issue12014@psf.upfronthosting.co.za>


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

"""
>>> d = {"{0}": "spam"}
>>> # a matched pair of braces. What's inside is considered markup.
... 
>>> "{0}".format(d)
"{'{0}': 'spam'}"
>>> # a matched pair of braces. Inside is a matched pair of braces, and what's inside of that is not considered markup.
"""

I'm not sure what' you're getting at. "{0}" (which is indeed "markup") is replaced by str(d), which is "{'{0}': 'spam'}".

"""
... 
>>> "{0[{0}]}".format(d)
'spam'
>>> 
"""

Again, I'm not sure what you're getting at. The inner "{0}" is not interpreted (per the PEP). So the entire string is replaced by d['{0}'], or 'spam'.

Let me try to explain it again. str.format() parses the string, looking for matched sets of braces. In your last example above, the very first character '{' is matched to the very last character '}'. They match, in sense that all of the nested ones inside match. Once the markup is separated from the character data, the interpretation of what's inside the markup is then done. In this example, there is no character data.

I apologize if I'm explaining this poorly.

----------

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

From report at bugs.python.org  Sat Jun  4 00:52:59 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 03 Jun 2011 22:52:59 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <BANLkTim9t9edZZ3+Fkh+KPXs4Bvc8=dKMA@mail.gmail.com>
Message-ID: <4DE965CA.6090306@v.loewis.de>


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

> One reason is the desire to avoid loading Python module from a
> C-module.

This desire is indeed no guidance for Python development; the opposite
is the case. The only exception may be bootstrapping issues, which I
claim are irrelevant in this case.

----------

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

From report at bugs.python.org  Sat Jun  4 00:58:05 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Jun 2011 22:58:05 +0000
Subject: [issue12220] minidom xmlns not handling spaces in xmlns attribute
	value field
In-Reply-To: <1306789573.92.0.875996944294.issue12220@psf.upfronthosting.co.za>
Message-ID: <1307141885.13.0.942056269476.issue12220@psf.upfronthosting.co.za>


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

SyntaxErrors refer to Python syntax errors; they are raised during parsing of *Python* code. An error in the value given to a Python sensibly raises a ValueError unless a module does something more specific.

>From the xml.dom doc
"DOM Level 2 recommendation defines a single exception, DOMException"
One subclass is "exception xml.dom.SyntaxErr -- Raised when an invalid or illegal string is specified." which would be appropriate here.

However, "The xml.dom.minidom module is essentially a DOM 1.0-compatible DOM with some DOM 2 features (primarily namespace features)." In particular, "DOMException is currently not supported in xml.dom.minidom. Instead, xml.dom.minidom uses standard Python exceptions such as TypeError and AttributeError." or ValueError.

An improved error report could go into 2.7/3.2.
A change in minidom spec to use DOMException would be a feature request for 3.3 or later (and a bigger project -- code welcome). For the moment, I am assuming that you are requesting the former.

A Python exception is not a crash. A crash is a Segmentation Fault (*nix) or 'Your program stopped unexpectedly' (Windows)

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

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

From report at bugs.python.org  Sat Jun  4 00:59:20 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 03 Jun 2011 22:59:20 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1307134364.91.0.937648462344.issue12226@psf.upfronthosting.co.za>
Message-ID: <4DE96747.9070005@v.loewis.de>


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

> I can fill separate bug for packaging, server certificate validation
> and support for non-SSL builds of python (for which there is
> workaround with upload -r <server> option that I've just discovered),
> but it is an additional delay and the only reason I invested some
> time into this issue is because I saw RC announcements.

This effort was wasted - there is zero chance that this can go into
a release candidate. Only fundamental flaws (such as being unable to
compile Python on a major platform, or serious regressions) should be
considered for changes between a rc and the final release.

----------

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

From report at bugs.python.org  Sat Jun  4 01:05:31 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Jun 2011 23:05:31 +0000
Subject: [issue12224] problem with siginterrupt
In-Reply-To: <1306841014.72.0.255052920445.issue12224@psf.upfronthosting.co.za>
Message-ID: <1307142331.61.0.568928907659.issue12224@psf.upfronthosting.co.za>


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

Victor, I understand your response as saying that there is no bug, which would suggest closing this. Correct? If not, what is the requested action?

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

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

From report at bugs.python.org  Sat Jun  4 01:14:22 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Jun 2011 23:14:22 +0000
Subject: [issue12232] embedded python import cmath
In-Reply-To: <1306888300.23.0.381408538703.issue12232@psf.upfronthosting.co.za>
Message-ID: <1307142862.43.0.545784350681.issue12232@psf.upfronthosting.co.za>


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

Hanging is different from crashing.
2.6 and 3.1 (soon) are only open for security issues.
Perhaps your system is missing something needed for the import.

If you want this to stay open, retest with 2.7 or 3.2 and give much more information: your system/OS, C/C++ compiler, your Python binary (copy the startup line in the interactive interpreter), and a minimal code that shows the problem.

----------
nosy: +terry.reedy
stage:  -> test needed
type: crash -> behavior
versions:  -Python 2.6

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

From report at bugs.python.org  Sat Jun  4 02:12:54 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jun 2011 00:12:54 +0000
Subject: [issue12237] Document how to open non-default webbrowser
In-Reply-To: <1307006042.24.0.905858439151.issue12237@psf.upfronthosting.co.za>
Message-ID: <1307146374.99.0.00447578732885.issue12237@psf.upfronthosting.co.za>


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

The intended method of using a non-default browser is well documented and the OP did exactly the right thing. However, even if Opera is present, the 'right thing' does not work because nothing but iexplorer gets registered (and that not completely usefully), even if present on the system, because the registration code is buggy, as discussed in #10799.

Hirch, if you had clicked Search and entered 'webbrowser' in the 'All text' box, you could have found that report.

If you add a note to #10799 as to the exact default location of Opera (within Program Files, I presume), it might eventually help.

----------
components: +Library (Lib)
nosy: +georg.brandl, terry.reedy
resolution:  -> duplicate
status: open -> closed
superseder:  -> Improve webbrowser.open doc (and, someday, behavior?)
type:  -> behavior

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

From report at bugs.python.org  Sat Jun  4 02:13:33 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jun 2011 00:13:33 +0000
Subject: [issue10799] Improve webbrowser (.open) doc and behavior
In-Reply-To: <1293767251.94.0.704365544958.issue10799@psf.upfronthosting.co.za>
Message-ID: <1307146413.9.0.840319332017.issue10799@psf.upfronthosting.co.za>


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

Upon further experimentation, I realize that I can only open in Firefox because I have it set as my default browser. It would otherwise be inaccessible because it is not in the _browser registry. It also appears that I cannot intentionally use Internet Explorer because it also in not registered (except under the full path names used as a backup).

>>> webbrowser._browsers
{'windows-default': [<class 'webbrowser.WindowsDefault'>, None], 'c:\\program files\\internet explorer\\iexplore.exe': [None, <webbrowser.BackgroundBrowser object at 0x01000ED0>]}

If I understand the Windows code quoted before, the Class Names in the table would be different (BackgroundBrowser) on Windows if it did work.

Related issues
#8232 webbrowser.open incomplete on Windows
#8936 webbrowser regression on windows
#12237 Document how to open non-default webbrowser

----------
components: +Documentation
title: Improve webbrowser.open doc (and, someday, behavior?) -> Improve webbrowser (.open) doc and behavior
type:  -> behavior

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

From report at bugs.python.org  Sat Jun  4 02:19:49 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jun 2011 00:19:49 +0000
Subject: [issue6490] os.popen documentation  is probably wrong
In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
Message-ID: <1307146789.74.0.437949443649.issue6490@psf.upfronthosting.co.za>


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


----------
title: os.popen documentation in 2.6 is probably wrong -> os.popen documentation  is probably wrong

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

From report at bugs.python.org  Sat Jun  4 02:36:31 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Sat, 04 Jun 2011 00:36:31 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1307147791.34.0.928857581865.issue12014@psf.upfronthosting.co.za>


Ben Wolfson <wolfson at gmail.com> added the comment:

"""
>From the PEP: "Format strings consist of intermingled character data and markup."
"""

I know. Here is an example of a format string:

"hello, {0}"

Here is the character data from that format string:

"hello, "

Here is the markup:

"{0}"

This follows *directly* from the definition of "character data", which I've quoted several times now. In the following expression:

"{0}".format(1)

there is NO character data, because there is NOTHING which is "which is transferred unchanged from the format string to the output string".

The "{0}" doesn't appear in the output string at all. And the 1 isn't transferred unchanged: it has str() called on it. Since there is nothing which meets the definition of character data, there is nothing which *is* character data in the string, regarded as a format string. It is pure markup---it consists solely of a replacement field delimited by curly braces. I really don't see why this matters at all, but, nevertheless, I apologize if I'm explaining it poorly.

"""
Again, I'm not sure what you're getting at. The inner "{0}" is not interpreted (per the PEP). So the entire string is replaced by d['{0}'], or 'spam'.

Let me try to explain it again. str.format() parses the string, looking for matched sets of braces. In your last example above, the very first character '{' is matched to the very last character '}'. They match, in sense that all of the nested ones inside match. Once the markup is separated from the character data, the interpretation of what's inside the markup is then done. In this example, there is no character data.
"""

Yes, there is no character data. And I understand perfectly what is happening. Here's the problem: your description of what the implementation does is incorrect. You say that 

"""
The current implementation of str.format() finds matched pairs of braces and call what's inside "markup", then parse that markup.
"""

Now, the only reason for thinking that this:

"{0[}]}"

should be treated differently from this:

"{0[a]}"

is that inside square brackets curly brackets indicate replacement fields. If you want to justify what the current implementation does as an implementation of the PEP and an interpretation of what the PEP says, you *have* to think that. But if you think that, then the current implementation should *not* treat this:

"{0[{0}]}"

the way it does, because it does *not* treat the interior curly braces as indications of a replacement field---or rather, it does at one point in the source (in MarkupIterator_next) and it doesn't at another (in FieldNameIterator). I agree that what the current implementation does in the last example is in fact correct. But if it's correct in the one case, it's incorrect in the other, and vice versa. There is no justification, in terms of the PEP, for the present behavior.

----------

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

From report at bugs.python.org  Sat Jun  4 02:53:06 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jun 2011 00:53:06 +0000
Subject: [issue12215] TextIOWrapper: issues with interlaced read-write
In-Reply-To: <1306759084.05.0.928785750761.issue12215@psf.upfronthosting.co.za>
Message-ID: <1307148786.7.0.444971075452.issue12215@psf.upfronthosting.co.za>


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

Perhaps the stdio requirement was based on an underlying OS (*nix?) requirement, which io has to fulfill even if it does not use stdio.

Stdio was, I presume, optimized for speed.  In the relatively rare case of mixed read/write, it *should* put the burden on the programmer.  Python is a bit different.

----------

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

From report at bugs.python.org  Sat Jun  4 03:03:07 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 04 Jun 2011 01:03:07 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1307149387.92.0.167963828477.issue12014@psf.upfronthosting.co.za>


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

We're going to have to agree to disagree. I believe that "{0[}]}" is the markup "{0[}" followed by the character data "]}".

----------

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

From report at bugs.python.org  Sat Jun  4 03:48:56 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 04 Jun 2011 01:48:56 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307152136.46.0.330771135988.issue12248@psf.upfronthosting.co.za>


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

Ah, I wondered about that when I saw Barry was using old-style classes in his example. Perhaps the answer then is to add a PyInstance_Check() to skip invocation of __dir__() completely for old-style classes?

----------

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

From report at bugs.python.org  Sat Jun  4 03:52:42 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 04 Jun 2011 01:52:42 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307152136.46.0.330771135988.issue12248@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=9GYBJiZ+5fSAAFdxnfGyY-dr0ug@mail.gmail.com>


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

2011/6/3 Nick Coghlan <report at bugs.python.org>:
>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> Ah, I wondered about that when I saw Barry was using old-style classes in his example. Perhaps the answer then is to add a PyInstance_Check() to skip invocation of __dir__() completely for old-style classes?

Uh, well, part of point of my checkin was to fix old style class
__dir__(). I think this is a bug in the package we're just exposing.

----------

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

From report at bugs.python.org  Sat Jun  4 04:21:46 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 04 Jun 2011 02:21:46 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307154106.14.0.763890322727.issue12248@psf.upfronthosting.co.za>


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

I would guess that if you instead skipped __dir__ completely for old style classes it would expose a different bug in this or some other package.

----------

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

From report at bugs.python.org  Sat Jun  4 04:26:32 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 04 Jun 2011 02:26:32 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307154392.29.0.271051612232.issue12248@psf.upfronthosting.co.za>


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

It would be broken in the same way that it was broken in 2.7.1 though. That can be a plus when it comes to maintenance releases.

OTOH, this does turn a silent failure (__dir__() ignored on old-style classes) into a noisy failure (must return a list).

If you make Barry's classes new-style, they break in 2.7.1 as well, so I'm coming around to a point of view that this is a legitimate fix that reveals a real bug in third party code (i.e. anyone that hits this had a __dir__ that previously wasn't getting invoked)

----------

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

From report at bugs.python.org  Sat Jun  4 04:40:46 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 04 Jun 2011 02:40:46 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307155246.81.0.0457777399071.issue12248@psf.upfronthosting.co.za>


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

I believe the type check was gratuitous to begin with and should be removed.  There's no reason the result has to be a list.

----------

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

From report at bugs.python.org  Sat Jun  4 04:43:14 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 04 Jun 2011 02:43:14 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307155246.81.0.0457777399071.issue12248@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=p3kQ=-+8Q93Gk10ZHwn-XFbMknA@mail.gmail.com>


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

2011/6/3 Raymond Hettinger <report at bugs.python.org>:
>
> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:
>
> I believe the type check was gratuitous to begin with and should be removed. ?There's no reason the result has to be a list.

The reason for it is that the sort() method is called on it.

----------

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

From report at bugs.python.org  Sat Jun  4 05:00:57 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 04 Jun 2011 03:00:57 +0000
Subject: [issue10027] os.lstat/os.stat don't set st_nlink on Windows
In-Reply-To: <1286289327.29.0.159315245099.issue10027@psf.upfronthosting.co.za>
Message-ID: <1307156457.63.0.566442386485.issue10027@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

This code has changed a lot since originally being committed, so I'll handle backporting in #12084 which has the latest changes.

----------
status: open -> closed

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

From report at bugs.python.org  Sat Jun  4 06:46:27 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 04 Jun 2011 04:46:27 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307162787.42.0.487254767736.issue12248@psf.upfronthosting.co.za>


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

Can sorted() be used instead?

----------

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

From report at bugs.python.org  Sat Jun  4 07:01:15 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 04 Jun 2011 05:01:15 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1307163675.91.0.544188543777.issue12226@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I believe that's a very personal judgement. For me exposing core Python development accounts is a fundamental flaw. The more accounts are collected, the more real are attacks through PyPI package injection.

----------

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

From report at bugs.python.org  Sat Jun  4 07:03:04 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 04 Jun 2011 05:03:04 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307163784.22.0.0158552671446.issue12248@psf.upfronthosting.co.za>


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

or something like:

   result = obj.__dir__()
   if not isinstance(result, list):
       result = list(result)
   result.sort()
   return result

----------

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

From report at bugs.python.org  Sat Jun  4 08:28:06 2011
From: report at bugs.python.org (umedoblock)
Date: Sat, 04 Jun 2011 06:28:06 +0000
Subject: [issue12211] math.copysign must keep object type.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1307168886.22.0.804155685134.issue12211@psf.upfronthosting.co.za>


umedoblock <umedoblock at gmail.com> added the comment:

abs() behavior show below.
>>> type(abs(-1))
<class 'int'>
>>> type(abs(-1.0))
<class 'float'>

we should fix this problem if write
"Return abs(x) with the sign of y"

I'd like to try this problem if need fix.
I'm going to attach the patch.

----------

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

From report at bugs.python.org  Sat Jun  4 11:18:26 2011
From: report at bugs.python.org (Tim Golden)
Date: Sat, 04 Jun 2011 09:18:26 +0000
Subject: [issue11583] os.path.isdir() is slow on windows
In-Reply-To: <1300354713.42.0.570312056806.issue11583@psf.upfronthosting.co.za>
Message-ID: <1307179106.55.0.0686554084311.issue11583@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

Code looks good and tests pass. Only one thing: the code in the patched lib\ntpath.py still refers to FindFirstFile

----------

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

From report at bugs.python.org  Sat Jun  4 11:26:58 2011
From: report at bugs.python.org (=?utf-8?q?Domen_Ko=C5=BEar?=)
Date: Sat, 04 Jun 2011 09:26:58 +0000
Subject: [issue12234] unittest2 could enable regex debugging for more
	information
In-Reply-To: <1306933404.89.0.697079292496.issue12234@psf.upfronthosting.co.za>
Message-ID: <1307179618.08.0.576531577105.issue12234@psf.upfronthosting.co.za>


Domen Ko?ar <ielectric at gmail.com> added the comment:

I see, currently re module does not support debugging for matching a string. Even the upcoming new regex implementation does not support it.

----------

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

From report at bugs.python.org  Sat Jun  4 12:11:03 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 04 Jun 2011 10:11:03 +0000
Subject: [issue12224] problem with siginterrupt
In-Reply-To: <1306841014.72.0.255052920445.issue12224@psf.upfronthosting.co.za>
Message-ID: <1307182263.49.0.251382514003.issue12224@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Actually, it's part of a more general problem with EINTR being returned by many posix/socket module functions, see for example issue #7978.
On the one hand, having to retry manually on EINTR is cumbersome, on the other hand, some code might rely on this - receiving EINTR - and the posix module policy is to expose syscalls as-is.
This should probably be closed as duplicate of issue #9867.

----------
nosy: +charles-francois.natali

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

From report at bugs.python.org  Sat Jun  4 12:19:25 2011
From: report at bugs.python.org (Stephen Thorne)
Date: Sat, 04 Jun 2011 10:19:25 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1307182765.46.0.818910056995.issue11104@psf.upfronthosting.co.za>


Stephen Thorne <stephen at thorne.id.au> added the comment:

I've taken the sdist.patch and wrote some tests for it. The resulting patch is attached as 'manifest-respect.patch'.

----------
nosy: +jerub
Added file: http://bugs.python.org/file22242/manifest-respect.patch

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

From report at bugs.python.org  Sat Jun  4 13:22:40 2011
From: report at bugs.python.org (Stephen Thorne)
Date: Sat, 04 Jun 2011 11:22:40 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1307186560.5.0.216172513551.issue11104@psf.upfronthosting.co.za>


Stephen Thorne <stephen at thorne.id.au> added the comment:

This patch is tested against the 3.1 and default branches, the previous patch attached was against the 2.7 branch.

----------
Added file: http://bugs.python.org/file22243/manifest-respect-3.patch

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

From report at bugs.python.org  Sat Jun  4 13:28:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Jun 2011 11:28:39 +0000
Subject: [issue12224] problem with siginterrupt
In-Reply-To: <1306841014.72.0.255052920445.issue12224@psf.upfronthosting.co.za>
Message-ID: <1307186919.97.0.495472876232.issue12224@psf.upfronthosting.co.za>


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

> Victor, I understand your response as saying that there is no bug,
> which would suggest closing this. Correct? If not, what is
> the requested action?

siginterrupt(False) has no effect on select().

I listed some solutions to not interrupt select() on a signal (avoid completly EINTR). Issues #7978 and #9867 try the other solution, handle EINTR (retry select() on EINTR). I think that most users prefer the later (handle EINTR), so let's close as a duplicate.

@Zhiping Deng: Reopen the issue if you want the first solution :-)

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

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

From report at bugs.python.org  Sat Jun  4 13:31:40 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Sat, 04 Jun 2011 11:31:40 +0000
Subject: [issue12185] Decimal documentation lists "first" and "second"
	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1307187100.76.0.754072605186.issue12185@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Hi Adam,
I couldn?t see that from the threat context, I'm new to this and just
wanted to learn the work flow and tools so I've just picked up an
easy issue to start with. Anyway your patch seems more complete.

----------

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

From report at bugs.python.org  Sat Jun  4 14:26:07 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Jun 2011 12:26:07 +0000
Subject: [issue12257] Use PYPACKAGING_USE_SDK envvar instead of
	DISTUTILS_USE_SDK
In-Reply-To: <1307120894.91.0.571532721021.issue12257@psf.upfronthosting.co.za>
Message-ID: <1307190367.81.0.221116915791.issue12257@psf.upfronthosting.co.za>


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

I don't think the name should be changed. If anything should be done, we should reconsider whether this flag is actually needed, or whether some other approach to selecting a compiler can be taken.

----------

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

From report at bugs.python.org  Sat Jun  4 15:12:38 2011
From: report at bugs.python.org (Zhiping Deng)
Date: Sat, 04 Jun 2011 13:12:38 +0000
Subject: [issue12224] problem with siginterrupt
In-Reply-To: <1306841014.72.0.255052920445.issue12224@psf.upfronthosting.co.za>
Message-ID: <1307193158.73.0.684239047425.issue12224@psf.upfronthosting.co.za>


Zhiping Deng <kofreestyler at gmail.com> added the comment:

I think the problem is that after a user calles signal.siginterrupt(False), 
he would expect that the socket.recv should handles EINTR properly 
for him because it's the behaviour in c level. 
He doesn't know socket.recv() calles select(2) internally and he needn't.

Or at least this should be documented in signal.siginterrupt().

----------

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

From report at bugs.python.org  Sat Jun  4 16:33:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Jun 2011 14:33:46 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1307198026.95.0.503396895817.issue12226@psf.upfronthosting.co.za>


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

> I think there should be a warning that the connection is
> unauthenticated (i.e. not secure). Users tend to be upset if they see
> 'https' and later find out that no certificates were verified.

Thanks Stephan, that was on my mind but I forgot it.  I?m -1 on using https if no validation is performed.

> I believe that's a very personal judgement.

Not really; it?s an explanation of our release rules, exposed by one of the older developers.

> For me exposing core Python development accounts is a fundamental
> flaw.

What is a core Python development account?

----------

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

From report at bugs.python.org  Sat Jun  4 16:38:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Jun 2011 14:38:54 +0000
Subject: [issue12246] create installation path if it's non-existent
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307198334.27.0.938245252091.issue12246@psf.upfronthosting.co.za>


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

We do not want to create a directory under $prefix before installation.  This would be a sort of dirty half-installation.  When you have an uninstalled, unconfigured Python, you cannot install modules without giving a prefix option: this sounds good to me.

----------

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

From report at bugs.python.org  Sat Jun  4 16:39:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Jun 2011 14:39:20 +0000
Subject: [issue12231] regrtest: add -k and -K options to filter tests by
	function/file names
In-Reply-To: <1306886173.49.0.536773734975.issue12231@psf.upfronthosting.co.za>
Message-ID: <1307198360.36.0.862801620366.issue12231@psf.upfronthosting.co.za>


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

File name, class name, method name unless I misremember.

----------

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

From report at bugs.python.org  Sat Jun  4 16:43:29 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Jun 2011 14:43:29 +0000
Subject: [issue12211] math.copysign must keep object type.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1307198609.04.0.0162109872269.issue12211@psf.upfronthosting.co.za>


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

How about something like: "Return a float with the magnitude of x but the sign of y."?

The behaviour of math.copysign with respect to non-float inputs matches that of almost all the other math module functions:  integer arguments are first converted to floats, and then the underlying libm function applied.  I'm not convinced that changing the behaviour of copysign to produce integer results for integer argument would be a good idea.

----------

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

From report at bugs.python.org  Sat Jun  4 16:46:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Jun 2011 14:46:35 +0000
Subject: [issue12257] Rework/replace use of DISTUTILS_USE_SDK in packaging
In-Reply-To: <1307120894.91.0.571532721021.issue12257@psf.upfronthosting.co.za>
Message-ID: <1307198795.57.0.857249558708.issue12257@psf.upfronthosting.co.za>


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

Agreed.  Thanks for the insight.

----------
title: Use PYPACKAGING_USE_SDK envvar instead of DISTUTILS_USE_SDK -> Rework/replace use of DISTUTILS_USE_SDK in packaging

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

From report at bugs.python.org  Sat Jun  4 16:47:35 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Jun 2011 14:47:35 +0000
Subject: [issue12185] Decimal documentation lists "first" and "second"
	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1307198855.07.0.583860516436.issue12185@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/issue12185>
_______________________________________

From report at bugs.python.org  Sat Jun  4 16:50:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Jun 2011 14:50:07 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1307199007.35.0.72955751284.issue10935@psf.upfronthosting.co.za>


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

Here?s my try at making the spec more explicit about str subclasses.

----------
keywords: +patch
Added file: http://bugs.python.org/file22244/pep-3333-no-subclasses.diff

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

From report at bugs.python.org  Sat Jun  4 16:51:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Jun 2011 14:51:41 +0000
Subject: [issue11557] Increase coverage in logging module
In-Reply-To: <1300202455.33.0.229381478379.issue11557@psf.upfronthosting.co.za>
Message-ID: <1307199101.6.0.0527641607173.issue11557@psf.upfronthosting.co.za>


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

I saw this commit pass by and noticed a few instances of non-idiomatic unittest code, like unnecessary lambdas or overuse of assertEqual where other methods would give more useful messages in case of failure.  Here?s a patch to better it.

----------
assignee: vinay.sajip -> trentm
nosy: +eric.araujo, trentm
status: closed -> open
Added file: http://bugs.python.org/file22245/cleanup-test_logging.diff

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

From report at bugs.python.org  Sat Jun  4 16:51:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Jun 2011 14:51:59 +0000
Subject: [issue11557] Increase coverage in logging module
In-Reply-To: <1300202455.33.0.229381478379.issue11557@psf.upfronthosting.co.za>
Message-ID: <1307199119.75.0.818901049871.issue11557@psf.upfronthosting.co.za>


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


----------
assignee: trentm -> vinay.sajip
nosy:  -trentm

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

From report at bugs.python.org  Sat Jun  4 16:54:45 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Jun 2011 14:54:45 +0000
Subject: [issue12164] str.translate docstring doesn't mention that 'table' can
	be None
In-Reply-To: <1306214084.99.0.386690557918.issue12164@psf.upfronthosting.co.za>
Message-ID: <1307199285.42.0.222610863212.issue12164@psf.upfronthosting.co.za>


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

Thanks for the patches!  Here's a slight expansion of the wording on your second patch:

 Return a copy of the string S, where all characters occurring
 in the optional argument deletechars are removed, and the
 remaining characters have been mapped through the given
 translation table, which must be a string of length 256 or None.
 If the table argument is None, no translation is applied and
 the translation simply removes the characters in deletechars.

What do you think?

----------
assignee: docs at python -> mark.dickinson

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

From report at bugs.python.org  Sat Jun  4 17:04:35 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Jun 2011 15:04:35 +0000
Subject: [issue12127] Inconsistent leading zero treatment
In-Reply-To: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>
Message-ID: <1307199875.03.0.528615699391.issue12127@psf.upfronthosting.co.za>


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

Closing, based on feedback in the comments.  Maybe one day...

----------
resolution:  -> later
status: open -> closed

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

From report at bugs.python.org  Sat Jun  4 17:14:43 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Jun 2011 15:14:43 +0000
Subject: [issue12245] Document the meaning of FLT_ROUNDS constants for
	sys.float_info
In-Reply-To: <1307044030.93.0.176037757521.issue12245@psf.upfronthosting.co.za>
Message-ID: <1307200483.18.0.174086604847.issue12245@psf.upfronthosting.co.za>


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

float_info.rounds is a bit of an odd fish, and I think it was probably a mistake to include it in sys.float_info in the first place.

All the other float_info fields relate to parameters of the floating-point format, which is fixed, useful information.  In contrast, float_info.rounds gives information about the current FPU settings, which are variable.  Moreover, it doesn't do that very well:  all it does is give information about the FPU settings at the time that Python was compiled, which isn't really very helpful (and perhaps not even that:  it reports the value of FLT_ROUNDS, which may not even reflect those FPU settings accurately).  I wouldn't mind seeing this field fade quietly into obscurity.

FWIW, the value is taken from C's FLT_ROUNDS, and its interpretation is *supposed* to be the following (C99 5.2.4.2.2, para 7):

  -1:  The compiler was unable to determine rounding mode.
   0:  Round towards zero.
   1:  Round to nearest (this is the most likely value for
       float_info.rounds on common platforms).
   2:  Round towards positive infinity
   3:  Round towards negative infinity.

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

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

From report at bugs.python.org  Sat Jun  4 17:29:56 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 04 Jun 2011 15:29:56 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307201396.52.0.075009865874.issue12248@psf.upfronthosting.co.za>


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

Using sorted() makes sense to me.  

Note that I've at least accomplished one goal, which is to have a tracker issue that discusses the merits of the change.  That way, no matter what the RM decides, I can at least point to an issue for justification when I resolve the downstream bug. :)

Thanks!

----------

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

From report at bugs.python.org  Sat Jun  4 17:39:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Jun 2011 15:39:03 +0000
Subject: [issue8286] distutils: path '[...]' cannot end with '/' -- need
	better error message
In-Reply-To: <1270180979.93.0.404335172952.issue8286@psf.upfronthosting.co.za>
Message-ID: <1307201943.95.0.121931288732.issue8286@psf.upfronthosting.co.za>


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

There is a simple way to fix this: change one line in sdist to catch ValueErrors in addition to DistutilsTemplateError.  Users will get a on-line warning message with the ill-formed manifest line number instead of a wall of traceback.

This is clearly a bug fix IMO: it is documented that distutils code can raise standard exceptions in addition to Distutils* errors, so here it?s not a new feature but a fix for sdist.

(Another way to fix this, would be to catch ValueError raised by convert_path in filelist and wrap it in a DistutilsTemplateError, but I?m not sure it really buys us anything.  Maybe it would be the better fix for Packaging, where the Manifest class is intended for public use.)

----------
assignee: tarek -> eric.araujo
components: +Distutils2
nosy: +alexis
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Sat Jun  4 17:39:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Jun 2011 15:39:42 +0000
Subject: [issue8286] distutils: path '[...]' cannot end with '/' -- need
	better error message
In-Reply-To: <1270180979.93.0.404335172952.issue8286@psf.upfronthosting.co.za>
Message-ID: <1307201982.28.0.246231973275.issue8286@psf.upfronthosting.co.za>


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

a one-line*

I?ll have a patch up for review shortly.

----------

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

From report at bugs.python.org  Sat Jun  4 17:42:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Jun 2011 15:42:41 +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: <1307202161.49.0.497944885949.issue11934@psf.upfronthosting.co.za>


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

Isn?t zlib built by setup.py anyway?

----------
nosy: +eric.araujo
resolution: invalid -> 
status: pending -> open

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

From report at bugs.python.org  Sat Jun  4 17:47:24 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Jun 2011 15:47:24 +0000
Subject: [issue12232] embedded python import cmath
In-Reply-To: <1306888300.23.0.381408538703.issue12232@psf.upfronthosting.co.za>
Message-ID: <1307202444.42.0.0940621423696.issue12232@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/issue12232>
_______________________________________

From report at bugs.python.org  Sat Jun  4 18:18:06 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Jun 2011 16:18:06 +0000
Subject: [issue12245] Document the meaning of FLT_ROUNDS constants for
	sys.float_info
In-Reply-To: <1307044030.93.0.176037757521.issue12245@psf.upfronthosting.co.za>
Message-ID: <1307204286.77.0.983797789516.issue12245@psf.upfronthosting.co.za>


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


----------
nosy: +christian.heimes

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

From report at bugs.python.org  Sat Jun  4 18:19:09 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Jun 2011 16:19:09 +0000
Subject: [issue12245] Document the meaning of FLT_ROUNDS constants for
	sys.float_info
In-Reply-To: <1307044030.93.0.176037757521.issue12245@psf.upfronthosting.co.za>
Message-ID: <1307204349.74.0.546333489804.issue12245@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> mark.dickinson

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

From report at bugs.python.org  Sat Jun  4 19:14:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 04 Jun 2011 17:14:34 +0000
Subject: [issue12080] decimal.py: performance in _power_exact
In-Reply-To: <1305448101.95.0.153633212441.issue12080@psf.upfronthosting.co.za>
Message-ID: <E1QSuQi-0007bZ-AO@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c3fe54781244 by Mark Dickinson in branch 'default':
Issue #12080: Fix a performance issue in Decimal._power_exact that causes some corner-case Decimal.__pow__ calls to take an unreasonably long time.
http://hg.python.org/cpython/rev/c3fe54781244

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

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

From report at bugs.python.org  Sat Jun  4 19:24:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 04 Jun 2011 17:24:25 +0000
Subject: [issue12080] decimal.py: performance in _power_exact
In-Reply-To: <1305448101.95.0.153633212441.issue12080@psf.upfronthosting.co.za>
Message-ID: <E1QSuaF-00086U-Cs@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 78d79499e7de by Mark Dickinson in branch '2.7':
Issue #12080: Fix a performance issue in Decimal._power_exact that caused some corner-case Decimal.__pow__ calls to take an unreasonably long time.
http://hg.python.org/cpython/rev/78d79499e7de

----------

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

From report at bugs.python.org  Sat Jun  4 19:25:22 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Jun 2011 17:25:22 +0000
Subject: [issue12080] decimal.py: performance in _power_exact
In-Reply-To: <1305448101.95.0.153633212441.issue12080@psf.upfronthosting.co.za>
Message-ID: <1307208322.6.0.0552004090882.issue12080@psf.upfronthosting.co.za>


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

Fixed for 3.3 and 2.7.

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

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

From report at bugs.python.org  Sat Jun  4 19:59:58 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 04 Jun 2011 17:59:58 +0000
Subject: [issue12080] decimal.py: performance in _power_exact
In-Reply-To: <1306072292.19.0.0160540322777.issue12080@psf.upfronthosting.co.za>
Message-ID: <20110604175805.GA3245@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Mark Dickinson <report at bugs.python.org> wrote:
> Here's a patch. Stefan, could you please review?

Mark, sorry for not replying earlier. The patch looks great.

I've also tested the patch in practice: I ran 700,000,000 random tests with
an exponent range of [-999999999, 999999999]. This took three days.

Without the patch, this would have been impossible; the range had to be
restricted to [-9999, 9999].

Unfortunately I got sidetracked reviewing the rest of the function (today
I started out on a mechanical proof of the nth-root part).

I *did* review the changes though, and I think they are correct.

----------

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

From report at bugs.python.org  Sat Jun  4 20:03:24 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 04 Jun 2011 18:03:24 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1307130469.16.0.861092248507.issue12014@psf.upfronthosting.co.za>
Message-ID: <20110604180320.GA1857@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

> PEP 3101 defines format strings as intermingled character data and markup. Markup defines replacement fields and is delimited by braces. Only after markup is extracted does the PEP talk about interpreting the contents of the markup.
> 
> So, given "{0[a}b]}" the parser first parses out the character data and the markup. The first piece of markup is "{0[a}". That gives a syntax error because it's missing a right bracket.
> 
> I realize you'd like the parser to find the markup as the entire string, but that's not how I read the PEP.

This is a good point, although the support of further replacement
fields inside format_specifiers requies the parser to count matching
braces, if the markup is to be extracted before its interpreted.

But disallowing unmathced '}' inside the replacement field doesn't
still explain why this shouldn't work:

    '{0[!]!r}'.format({'!': 'foo'})

I'm completely fine with disallowing '}', but it seems to me that
there's absolutely no reason to not parse the element_index and later
fields correctly with respect to '!' and ':'.

----------

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

From report at bugs.python.org  Sat Jun  4 20:08:50 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 04 Jun 2011 18:08:50 +0000
Subject: [issue12164] str.translate docstring doesn't mention that 'table' can
	be None
In-Reply-To: <1307199285.42.0.222610863212.issue12164@psf.upfronthosting.co.za>
Message-ID: <20110604180848.GB1857@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

> What do you think?

Sounds very good to my native Finnish ears :)

----------

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

From report at bugs.python.org  Sat Jun  4 20:13:30 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 04 Jun 2011 18:13:30 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307211210.01.0.737769026929.issue12248@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file22246/dir.patch

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

From report at bugs.python.org  Sat Jun  4 20:21:34 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 04 Jun 2011 18:21:34 +0000
Subject: [issue12164] str.translate docstring doesn't mention that 'table' can
	be None
In-Reply-To: <1306214084.99.0.386690557918.issue12164@psf.upfronthosting.co.za>
Message-ID: <1307211694.89.0.710349339393.issue12164@psf.upfronthosting.co.za>


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


----------
resolution:  -> accepted

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

From report at bugs.python.org  Sat Jun  4 20:42:44 2011
From: report at bugs.python.org (Soren Hansen)
Date: Sat, 04 Jun 2011 18:42:44 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307212964.67.0.685232672857.issue12248@psf.upfronthosting.co.za>


Soren Hansen <soren at linux2go.dk> added the comment:

When I first investigated this problem (I reported the original bug on Launchpad), my first attempt to address this issue in pymox had me quite stumped. The class in question has a __getattr__ method. Up until now, this hasn't affected the use of dir(), but it does now. I really just wanted it return whatever it used to return (since that has worked so far), but realising that this was an old-style class, I couldn't just call super(TheClass, self).__dir__().

So my question is: If this change stays (which seems clear given that the only changes proposed here are ways of relaxing the type requirement of the __dir__ method's return value, not reverting the change altogether), and I have an old-style class with a __getattr__ defined, how do I make that class return whatever it would have usually returned for __dir__()?

----------
nosy: +soren

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

From report at bugs.python.org  Sat Jun  4 20:53:53 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 04 Jun 2011 18:53:53 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307212964.67.0.685232672857.issue12248@psf.upfronthosting.co.za>
Message-ID: <BANLkTinruXPqSG-K7dCggZ6o2Wv_XEV=Dg@mail.gmail.com>


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

2011/6/4 Soren Hansen <report at bugs.python.org>:
>
> Soren Hansen <soren at linux2go.dk> added the comment:
>
> When I first investigated this problem (I reported the original bug on Launchpad), my first attempt to address this issue in pymox had me quite stumped. The class in question has a __getattr__ method. Up until now, this hasn't affected the use of dir(), but it does now. I really just wanted it return whatever it used to return (since that has worked so far), but realising that this was an old-style class, I couldn't just call super(TheClass, self).__dir__().
>
> So my question is: If this change stays (which seems clear given that the only changes proposed here are ways of relaxing the type requirement of the __dir__ method's return value, not reverting the change altogether), and I have an old-style class with a __getattr__ defined, how do I make that class return whatever it would have usually returned for __dir__()?

Yes, this is a limitation of magic methods on old style classes. The
usual method is something like this:

    def __getattr__(self, name):
        if name == "__dir__":
            return self.__dir__
        # Other stuff

Of course, the best fix is to use new-style classes. :)

----------

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

From report at bugs.python.org  Sat Jun  4 21:31:03 2011
From: report at bugs.python.org (sbt)
Date: Sat, 04 Jun 2011 19:31:03 +0000
Subject: [issue12262] Not Inheriting File Descriptors on Windows?
In-Reply-To: <1307133348.7.0.486629796214.issue12262@psf.upfronthosting.co.za>
Message-ID: <1307215863.92.0.44193118576.issue12262@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Although Windows fds are not inheritable, the handles associated with fds can be made inheritable.

A workaround for the fact fds are not inheritable is the following pattern:

1) The parent process converts the fd to a handle using _get_osfhandle(fd).

2) The parent process makes the handle inheritable (if it is not already) using SetHandleInformation() or DuplicateHandle().

3) The parent process starts the child process and passes the handle number on the commandline.

4) The child process gets the handle number by parsing the commandline.

5) The child process uses _open_osfhandle(handle, flags) to convert the handle into an fd.  

Note that Python has open_osfhandle() and get_osfhandle() in the msvcrt module.  In C, _open_osfhandle() and _get_osfhandle() are declared in io.h.

----------
nosy: +sbt

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

From report at bugs.python.org  Sat Jun  4 21:33:08 2011
From: report at bugs.python.org (Phillip J. Eby)
Date: Sat, 04 Jun 2011 19:33:08 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1307215988.37.0.138611679743.issue10935@psf.upfronthosting.co.za>


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

That change to the spec is fine, though you might also want to add something like, "Like all other WSGI specification types", since *all* types specified in WSGI are 'type()' not 'isinstance()'.

----------

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

From report at bugs.python.org  Sun Jun  5 00:13:08 2011
From: report at bugs.python.org (Soren Hansen)
Date: Sat, 04 Jun 2011 22:13:08 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <BANLkTinruXPqSG-K7dCggZ6o2Wv_XEV=Dg@mail.gmail.com>
Message-ID: <BANLkTikGU6ygqC28hVnQ0VwL9XrDhH+zbQ@mail.gmail.com>


Soren Hansen <soren at linux2go.dk> added the comment:

2011/6/4 Benjamin Peterson <report at bugs.python.org>:
> 2011/6/4 Soren Hansen <report at bugs.python.org>:
>> So my question is: If this change stays (which seems clear given that the only changes proposed here are ways of relaxing the type requirement of the __dir__ method's return value, not reverting the change altogether), and I have an old-style class with a __getattr__ defined, how do I make that class return whatever it would have usually returned for __dir__()?
>
> Yes, this is a limitation of magic methods on old style classes. The
> usual method is something like this:
>
> ? ?def __getattr__(self, name):
> ? ? ? ?if name == "__dir__":
> ? ? ? ? ? ?return self.__dir__
> ? ? ? ?# Other stuff
>
> Of course, the best fix is to use new-style classes. :)

If I do this:

===== test.py ======
class Foo:
    def __getattr__(self, name):
        if name == '__dir__':
            return self.__dir__
        return 'something else'

a = Foo()
print dir(a)
====================

After a lot of this:
  File "test.py", line 4, in __getattr__
    return self.__dir__
  File "test.py", line 4, in __getattr__
    return self.__dir__
  File "test.py", line 4, in __getattr__
    return self.__dir__

...I end up with a "RuntimeError: maximum recursion depth exceeded". I
can't say I'm surprised :)

----------

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

From report at bugs.python.org  Sun Jun  5 00:18:56 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 04 Jun 2011 22:18:56 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <BANLkTikGU6ygqC28hVnQ0VwL9XrDhH+zbQ@mail.gmail.com>
Message-ID: <BANLkTinrBZGK4s=G0irJPAnz80gVUtbUmQ@mail.gmail.com>


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

2011/6/4 Soren Hansen <report at bugs.python.org>:
>
> Soren Hansen <soren at linux2go.dk> added the comment:
>
> 2011/6/4 Benjamin Peterson <report at bugs.python.org>:
>> 2011/6/4 Soren Hansen <report at bugs.python.org>:
>>> So my question is: If this change stays (which seems clear given that the only changes proposed here are ways of relaxing the type requirement of the __dir__ method's return value, not reverting the change altogether), and I have an old-style class with a __getattr__ defined, how do I make that class return whatever it would have usually returned for __dir__()?
>>
>> Yes, this is a limitation of magic methods on old style classes. The
>> usual method is something like this:
>>
>> ? ?def __getattr__(self, name):
>> ? ? ? ?if name == "__dir__":
>> ? ? ? ? ? ?return self.__dir__
>> ? ? ? ?# Other stuff
>>
>> Of course, the best fix is to use new-style classes. :)
>
> If I do this:
>
> ===== test.py ======
> class Foo:
> ? ?def __getattr__(self, name):
> ? ? ? ?if name == '__dir__':
> ? ? ? ? ? ?return self.__dir__
> ? ? ? ?return 'something else'
>
> a = Foo()
> print dir(a)
> ====================
>
> After a lot of this:
> ?File "test.py", line 4, in __getattr__
> ? ?return self.__dir__
> ?File "test.py", line 4, in __getattr__
> ? ?return self.__dir__
> ?File "test.py", line 4, in __getattr__
> ? ?return self.__dir__
>
> ...I end up with a "RuntimeError: maximum recursion depth exceeded". I
> can't say I'm surprised :)

Ah, sorry I should have thought before writing that. :)
self.__class__.__dir__.__get__(self, self.__class__) should work,
though.

----------

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

From report at bugs.python.org  Sun Jun  5 00:30:59 2011
From: report at bugs.python.org (Soren Hansen)
Date: Sat, 04 Jun 2011 22:30:59 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <BANLkTinrBZGK4s=G0irJPAnz80gVUtbUmQ@mail.gmail.com>
Message-ID: <BANLkTikQ2qzcguaQZwi7+C1_rrtLZdaC_A@mail.gmail.com>


Soren Hansen <soren at linux2go.dk> added the comment:

2011/6/5 Benjamin Peterson <report at bugs.python.org>:
> 2011/6/4 Soren Hansen <report at bugs.python.org>:
>> ...I end up with a "RuntimeError: maximum recursion depth exceeded". I
>> can't say I'm surprised :)
> Ah, sorry I should have thought before writing that. :)
> self.__class__.__dir__.__get__(self, self.__class__) should work,
> though.

Yeah, that one does seem to work. Excellent, thanks!

----------

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

From report at bugs.python.org  Sun Jun  5 01:16:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Jun 2011 23:16:18 +0000
Subject: [issue12263] punycode codec ignores the error handler argument
In-Reply-To: <1307229378.45.0.142684435058.issue12263@psf.upfronthosting.co.za>
Message-ID: <1307229378.45.0.142684435058.issue12263@psf.upfronthosting.co.za>


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

b'abc\xff'.decode('punycode', 'ignore') raises the same error than b'abc\xff'.decode('punycode', 'replace') or b'abc\xff'.decode('punycode'): it uses the strict error handler, and simply ignores the error handler.

punycodec, as idna, should raise an exception if the error handler is different than strict.

----------
messages: 137666
nosy: haypo
priority: normal
severity: normal
status: open
title: punycode codec ignores the error handler argument
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jun  5 01:17:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Jun 2011 23:17:40 +0000
Subject: [issue12263] punycode codec ignores the error handler argument
In-Reply-To: <1307229378.45.0.142684435058.issue12263@psf.upfronthosting.co.za>
Message-ID: <1307229460.66.0.506334341604.issue12263@psf.upfronthosting.co.za>


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

base64_codec.py uses an assertion to check the error handler: it should use an if+raise (assertions are ignored in optimized mode, python -O).

----------

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

From report at bugs.python.org  Sun Jun  5 01:31:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Jun 2011 23:31:00 +0000
Subject: [issue12264] parser.expr(): reference count error if more than one
	argument is passed
In-Reply-To: <1307230260.08.0.858189035703.issue12264@psf.upfronthosting.co.za>
Message-ID: <1307230260.08.0.858189035703.issue12264@psf.upfronthosting.co.za>


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

import parser; parser.expr("a", "b") raises a TypeError('expr() takes at most 1 argument (2 given)') but corrupt also the reference count of an object (I don't know which one): "python: Modules/gcmodule.c:327: visit_decref: Assertion `gc->gc.gc_refs != 0' failed."

----------
components: Library (Lib)
messages: 137668
nosy: haypo
priority: normal
severity: normal
status: open
title: parser.expr(): reference count error if more than one argument is passed
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun  5 01:35:37 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jun 2011 23:35:37 +0000
Subject: [issue12211] math.copysign must keep object type.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1307230537.74.0.377698331949.issue12211@psf.upfronthosting.co.za>


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

> "Return a float with the magnitude of x but the sign of y."
This appears to describe both current behavior and what I believe was the intention. I would go with a doc patch based on this.
umedoblock, go ahead and make one.

It occurred to me, also, that as currently written, copysign 'should' return the type of the first arg. In C89, and I suspect in Python 1.0, all math functions return double (Python float). Like Mark, I am more inclined to change the doc than the code.

1. One use of copysign is to give a correctly signed 0.0. This does not apply to ints, where 0 is always unsigned. I do not know of any use of copysign in number (count/int) theory. (There could be, of course.)

2. icopysign(-1,0) == +1 (sign added for emphasis), whereas I believe that for ints, the answer should be -1, as 0 has no sign.

def icopysign(j,k):
    if (j > 0) and (k < 0) or (j < 0) and (k > 0):
        return -j
    return j
for j,k,i in ((1,1,1), (1,-1,-1), (-1,-1,-1), (-1, 1, 1),
              (1,0,1), (-1,0,-1)):
    assert icopysign(j,k) == i, (j,k,i)

This would certainly be up for debate if we changed the code, but there should be no difference in outputs for same value inputs. (This principle is the reason for / and //.) So lets leave copysign as a function defined on floats with inputs coerced to float if needed. Anyone who needs it for ints can define it for (-1,0) according to their need.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
stage:  -> needs patch
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Jun  5 02:07:20 2011
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 05 Jun 2011 00:07:20 +0000
Subject: [issue12246] create installation path if it's non-existent
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307232440.38.0.53797948784.issue12246@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

But this part of the code runs only when you want to install a 3rd party module isn't it? What you are proposing simply adds a delay, for the use will have to then add that directory manually. Or is there something I'm missing here?

----------

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

From report at bugs.python.org  Sun Jun  5 02:09:04 2011
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 05 Jun 2011 00:09:04 +0000
Subject: [issue12246] create installation path if it's non-existent
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307232544.11.0.12584139924.issue12246@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

s/use/user

----------

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

From report at bugs.python.org  Sun Jun  5 02:10:13 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 05 Jun 2011 00:10:13 +0000
Subject: [issue12232] embedded python import cmath
In-Reply-To: <1306888300.23.0.381408538703.issue12232@psf.upfronthosting.co.za>
Message-ID: <1307232613.9.0.708738783793.issue12232@psf.upfronthosting.co.za>


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

{It you reply by mail, please snip off the message you are replying to.}

>From what I have read, Windows is not a very pleasant environment for extending and embedding.

1. It works best if both Python and the extender or embedder are compiled with the same version (of Microsoft VC). Does Borland Builder 6 claim compatibility with any particular versions of MS C++?

2. Problems like this probably need a debug build of Python, which you would have to make yourself, and unlike *nux, Windows does not come with a system compiler. (There is now, however, a free VC Express, but I believe the one needed to go with 2.6 is no longer available ;-(.

I am inclined to close this both because it does not involve current Python and because it appears to be an issue with BB or the interface that is out of our control (as you said, Python by itself works fine). I am only leaving this open to give you a chance to provide evidence otherwise with 2.7 or 3.2.

I recommend that you might try the trivial 'import cmath\n' with other Python versions. Which versions would depend on what BB6 claims to be compatible with.

I also recommend that you ask for help on python-list or other forums
(such a Stackoverflow). Use a subject like "Embedding Python 2.6 with Borland Builder 6" This might catch the attention of someone who knows something about BB.

----------

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

From report at bugs.python.org  Sun Jun  5 03:38:20 2011
From: report at bugs.python.org (umedoblock)
Date: Sun, 05 Jun 2011 01:38:20 +0000
Subject: [issue12211] math.copysign must keep object type.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1307237900.1.0.620779309616.issue12211@psf.upfronthosting.co.za>


umedoblock <umedoblock at gmail.com> added the comment:

I made the patch.
But it cannot pass testCopysign().

math.copysign(1, -0.)
returns 1.

I hope to return -1.
But I don't know how to realize -0. as negative value.

Please help me.

----------
components: +Library (Lib) -Documentation
keywords: +patch
versions:  -Python 2.7, Python 3.3
Added file: http://bugs.python.org/file22249/math_copysign.patch

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

From report at bugs.python.org  Sun Jun  5 03:50:31 2011
From: report at bugs.python.org (umedoblock)
Date: Sun, 05 Jun 2011 01:50:31 +0000
Subject: [issue12211] math.copysign must keep object type.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1307238631.79.0.515718892248.issue12211@psf.upfronthosting.co.za>


Changes by umedoblock <umedoblock at gmail.com>:


Removed file: http://bugs.python.org/file22249/math_copysign.patch

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

From report at bugs.python.org  Sun Jun  5 03:51:04 2011
From: report at bugs.python.org (umedoblock)
Date: Sun, 05 Jun 2011 01:51:04 +0000
Subject: [issue12211] math.copysign must keep object type.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1307238664.71.0.713731949668.issue12211@psf.upfronthosting.co.za>


Changes by umedoblock <umedoblock at gmail.com>:


Added file: http://bugs.python.org/file22250/math_copysign.patch

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

From report at bugs.python.org  Sun Jun  5 04:04:16 2011
From: report at bugs.python.org (umedoblock)
Date: Sun, 05 Jun 2011 02:04:16 +0000
Subject: [issue12211] math.copysign must keep object type.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1307239456.65.0.0514539693261.issue12211@psf.upfronthosting.co.za>


Changes by umedoblock <umedoblock at gmail.com>:


Removed file: http://bugs.python.org/file22250/math_copysign.patch

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

From report at bugs.python.org  Sun Jun  5 04:09:16 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 05 Jun 2011 02:09:16 +0000
Subject: [issue12211] math.copysign must keep object type.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1307239756.62.0.696685380176.issue12211@psf.upfronthosting.co.za>


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

umedoblock: David, Mark, and I agree that this should be a doc issue, and so I suggested a DOC patch. So I do not know why you are screwing around with the code, or what you are trying to do with it, or why you are messing around with the version headers or why you think this is a 3.2 only issue.

----------

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

From report at bugs.python.org  Sun Jun  5 04:10:29 2011
From: report at bugs.python.org (umedoblock)
Date: Sun, 05 Jun 2011 02:10:29 +0000
Subject: [issue12211] math.copysign must keep object type.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1307239829.34.0.532473718677.issue12211@psf.upfronthosting.co.za>


umedoblock <umedoblock at gmail.com> added the comment:

sorry.
I fix my bug.

but this patch contain new fail...

math.copysign(-1., 0.)
returns 1.

----------
Added file: http://bugs.python.org/file22251/math_copysign.patch

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

From report at bugs.python.org  Sun Jun  5 04:20:44 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 05 Jun 2011 02:20:44 +0000
Subject: [issue12265] revamp argument errors
In-Reply-To: <1307240443.69.0.736494632157.issue12265@psf.upfronthosting.co.za>
Message-ID: <1307240443.69.0.736494632157.issue12265@psf.upfronthosting.co.za>


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

This patch completely rewrites errors given for positional error mismatches. The goal is to give more informative and correct errors.

Some examples:

>>> def f(): pass
... 
>>> f(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes 0 positional arguments but 1 was given
>>> f(1, kw=4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() got an unexpected keyword argument 'kw'
>>> def f(a, b=2): pass
... 
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes from 1 to 2 positional arguments but 0 were given
>>> f(1, 2, 3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes from 1 to 2 positional arguments but 3 were given
>>> def f(a, *b): pass
... 
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes at least 1 positional argument but 0 were given
>>> f(kw=4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() got an unexpected keyword argument 'kw'

When keyword-only arguments come into play, things get a bit more complicated. When a positional argument error occurs, it's confusing to report only the positional arguments, but not completely relevant to report keyword-only arguments. I comprise by putting the keyword-only argument information in parenthesis. Tell me if you have a better idea.

>>> def f(*, kw): pass
... 
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() requires keyword-only argument 'kw'
>>> f(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes 0 positional arguments but 1 was given
>>> f(3, kw=4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes 0 positional arguments but 1 positional arguments (and 1 keyword-only argument) were given

----------
components: Interpreter Core
files: argerror.patch
keywords: patch
messages: 137676
nosy: benjamin.peterson
priority: normal
severity: normal
stage: patch review
status: open
title: revamp argument errors
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22252/argerror.patch

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

From report at bugs.python.org  Sun Jun  5 04:24:02 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 05 Jun 2011 02:24:02 +0000
Subject: [issue12265] revamp argument errors
In-Reply-To: <1307240443.69.0.736494632157.issue12265@psf.upfronthosting.co.za>
Message-ID: <1307240642.9.0.691295050399.issue12265@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


Removed file: http://bugs.python.org/file22252/argerror.patch

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

From report at bugs.python.org  Sun Jun  5 04:24:12 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 05 Jun 2011 02:24:12 +0000
Subject: [issue12265] revamp argument errors
In-Reply-To: <1307240443.69.0.736494632157.issue12265@psf.upfronthosting.co.za>
Message-ID: <1307240652.98.0.339619113967.issue12265@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


Added file: http://bugs.python.org/file22253/argerror.patch

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

From report at bugs.python.org  Sun Jun  5 05:08:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Jun 2011 03:08:56 +0000
Subject: [issue12264] parser.expr(): reference count error if more than one
	argument is passed
In-Reply-To: <1307230260.08.0.858189035703.issue12264@psf.upfronthosting.co.za>
Message-ID: <E1QT3hu-0001mX-Vt@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3ffd8dea77bf by Benjamin Peterson in branch 'default':
only clear the parser error if it's set (closes #12264)
http://hg.python.org/cpython/rev/3ffd8dea77bf

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Jun  5 05:20:09 2011
From: report at bugs.python.org (Andreas Kloeckner)
Date: Sun, 05 Jun 2011 03:20:09 +0000
Subject: [issue4949] Constness in PyErr_NewException
In-Reply-To: <1231956299.48.0.0179649567226.issue4949@psf.upfronthosting.co.za>
Message-ID: <1307244009.59.0.988685308817.issue4949@psf.upfronthosting.co.za>


Andreas Kloeckner <inform at tiker.net> added the comment:

ping?

----------

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

From report at bugs.python.org  Sun Jun  5 05:36:46 2011
From: report at bugs.python.org (umedoblock)
Date: Sun, 05 Jun 2011 03:36:46 +0000
Subject: [issue12211] math.copysign must keep object type.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1307245006.37.0.638342849877.issue12211@psf.upfronthosting.co.za>


umedoblock <umedoblock at gmail.com> added the comment:

I attached DOC patch.

I misunderstand ?
Sorry...
I think that "go ahead and make one" means I shuold make the source patch.

I use just Python3.2. I didn't use Python 2.x, 3.0 and 3.1 in my programming life.
Therefore I reported version 3.2.
I should the versions to "3rd party" ?

----------
Added file: http://bugs.python.org/file22254/math.rst.patch

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

From report at bugs.python.org  Sun Jun  5 05:38:30 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 05 Jun 2011 03:38:30 +0000
Subject: [issue4949] Constness in PyErr_NewException
In-Reply-To: <1231956299.48.0.0179649567226.issue4949@psf.upfronthosting.co.za>
Message-ID: <1307245110.83.0.434591765392.issue4949@psf.upfronthosting.co.za>


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

This patch is not applicable anymore to 3.x.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Sun Jun  5 06:01:16 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 05 Jun 2011 04:01:16 +0000
Subject: [issue12265] revamp argument errors
In-Reply-To: <1307240443.69.0.736494632157.issue12265@psf.upfronthosting.co.za>
Message-ID: <1307246476.88.0.696425104529.issue12265@psf.upfronthosting.co.za>


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

Looks good in a desk review. Assuming the full test suite passes, +1 from me.

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

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

From report at bugs.python.org  Sun Jun  5 07:54:59 2011
From: report at bugs.python.org (py.user)
Date: Sun, 05 Jun 2011 05:54:59 +0000
Subject: [issue12266] str.capitalize contradicts
In-Reply-To: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>
Message-ID: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

specification

str.capitalize()?

    Return a copy of the string with its first character capitalized and the rest lowercased.


>>> '\u1ffc', '\u1ff3'
('?', '?')
>>> '\u1ffc'.isupper()
False
>>> '\u1ff3'.islower()
True
>>> s = '\u1ff3\u1ff3\u1ffc\u1ffc'
>>> s
'????'
>>> s.capitalize()
'????'
>>>

A: lower
B: title

A -> B & !B -> A

----------
components: Interpreter Core
messages: 137682
nosy: py.user
priority: normal
severity: normal
status: open
title: str.capitalize contradicts
versions: Python 3.1

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

From report at bugs.python.org  Sun Jun  5 08:08:52 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 05 Jun 2011 06:08:52 +0000
Subject: [issue12211] Better document math.copysign behavior.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1307254132.28.0.886028202331.issue12211@psf.upfronthosting.co.za>


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

Third party refers to things other than Pythonx.y code For instance, distutils2/distribute was for some years developed separately from the main codebase and was recently merged into the 3.3 repository. While separate, its issues were '3rd party'. That has nothing to do with this.

A patch against 3.2 is fine. It will almost certainly apply unchanged to both 3.3 and 2.7 since this part of the doc may have never changed since written. The patch looks fine so far. I see that you kept the line just under 80 characters. Now, can you expand it to also change the docstring for this function in the mathmodule.c file? I am not exactly sure where it is in the file, relative to the function code itself. As I remember, it is not as convenient as in Python files.
It currently looks like

    copysign(x, y)
    
    Return x with the sign of y.

When revising the "Return ..." part to match the doc, I think we should include the "On a platform ..." sentence also. If Mark disagrees, it would be easily removed. Notice that the indent is 1 or 2 more spaces, so the existing line would become too long. 'a platform' could be changed to 'platforms'. I personally like that better anyway.

----------
components: +Documentation -Library (Lib)
title: math.copysign must keep object type. -> Better document math.copysign behavior.
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Jun  5 09:00:52 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 05 Jun 2011 07:00:52 +0000
Subject: [issue12262] Not Inheriting File Descriptors on Windows?
In-Reply-To: <1307133348.7.0.486629796214.issue12262@psf.upfronthosting.co.za>
Message-ID: <1307257252.39.0.315441666398.issue12262@psf.upfronthosting.co.za>


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

Yes, that's probably how the cygwin runtime library works. But this method is difficult to use from a shell script.

----------

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

From report at bugs.python.org  Sun Jun  5 09:12:09 2011
From: report at bugs.python.org (Sebastian Ramacher)
Date: Sun, 05 Jun 2011 07:12:09 +0000
Subject: [issue1699259] replacing char* with const char* in sysmodule.c/.h
Message-ID: <1307257929.79.0.0887405640533.issue1699259@psf.upfronthosting.co.za>


Sebastian Ramacher <sebastinas at users.sourceforge.net> added the comment:

Since the patches are not applicable to Py 3.x and Py 2.7 is stable I'm closing this bug.

----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Sun Jun  5 10:12:08 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 05 Jun 2011 08:12:08 +0000
Subject: [issue12211] Better document math.copysign behavior.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1307261528.69.0.666365841805.issue12211@psf.upfronthosting.co.za>


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

> I think we should include the "On a platform ..."

Sure, sounds good.  One of the main things that makes copysign useful is that it distinguishes between -0.0 and 0.0.

----------

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

From report at bugs.python.org  Sun Jun  5 10:32:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Jun 2011 08:32:00 +0000
Subject: [issue11557] Increase coverage in logging module
In-Reply-To: <1300202455.33.0.229381478379.issue11557@psf.upfronthosting.co.za>
Message-ID: <E1QT8kZ-0001ZC-Bc@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 44139ece7a31 by Vinay Sajip in branch 'default':
Closes issue #11557: removal of non-idiomatic code in test_logging.
http://hg.python.org/cpython/rev/44139ece7a31

----------

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

From report at bugs.python.org  Sun Jun  5 10:33:22 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 05 Jun 2011 08:33:22 +0000
Subject: [issue11557] Increase coverage in logging module
In-Reply-To: <1300202455.33.0.229381478379.issue11557@psf.upfronthosting.co.za>
Message-ID: <1307262802.23.0.5330816369.issue11557@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
status: open -> closed

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

From report at bugs.python.org  Sun Jun  5 13:21:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Jun 2011 11:21:20 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <BANLkTimFzrUXGCU=wMCTUA0ad69w84Tv8g@mail.gmail.com>
Message-ID: <1307272877.3540.0.camel@localhost.localdomain>


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

> > What needs to happen to get recvmsg() supported in Python?
> 
> Well, I guess that the only reason is that no committer is motivated
> enough to bring this into Python: it's a rather large patch, and
> honestly, I'm not sure that many people are going to use it.
> The feature I personally like the most about sendmsg/recvmsg is the
> ability to do scatter-gather I/O, but if the performance is critical,
> then I won't be using Python.
> I know that sendmsg also has some other advantages (passing FDs,
> ancillary data...).

Modules/_multiprocessing already has code using sendmsg/recvmsg,
precisely to pass FDs IIRC.
Generic support for sendmsg() and recvmsg() in the socket module would
allow to rewrite that code in pure Python.

----------

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

From report at bugs.python.org  Sun Jun  5 13:22:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Jun 2011 11:22:51 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <1307272971.79.0.274030994244.issue12021@psf.upfronthosting.co.za>


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

> That's because of the _PyIO_ConvertSsize_t converter, which silently
> converts None to -1.
> There's probably a good reason for doing this in the _io module

I'm not sure about the original reason, but I find None as the default "omitted" value prettier than -1 myself, so I think it's a good thing :)

----------

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

From report at bugs.python.org  Sun Jun  5 13:25:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Jun 2011 11:25:42 +0000
Subject: [issue12213] BufferedRandom,
	BufferedRWPair: issues with interlaced read-write
In-Reply-To: <1306756651.54.0.607962084751.issue12213@psf.upfronthosting.co.za>
Message-ID: <1307273139.3540.1.camel@localhost.localdomain>


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

> My patch tries to fix interlaced read-write by always calling flush(),

Why do you need to call flush()? Can't you read from the buffer?

----------

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

From report at bugs.python.org  Sun Jun  5 13:29:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Jun 2011 11:29:21 +0000
Subject: [issue12134] json.dump much slower than dumps
In-Reply-To: <1306611729.68.0.107395742186.issue12134@psf.upfronthosting.co.za>
Message-ID: <1307273357.3540.4.camel@localhost.localdomain>


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

> "In CPython, json.dumps(o), by itself, is faster than json.dump(o,f),
> at the expense of using more space, because it creates the entire
> string at once, instead of incrementally writing each piece of o to f.
> However, f.write(json.dumps(o)) may not be faster."

Uh, talking about "CPython" is not very helpful here and only muddies
the waters IMO.
Something like "typical implementations of dump() will try to write the
result in small chunks and will therefore trade lower memory usage for
higher serialization time. If you have enough memory and care about
performance, consider using dumps() and write the result yourself with a
single write() call".

----------

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

From report at bugs.python.org  Sun Jun  5 13:30:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Jun 2011 11:30:09 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1307273409.82.0.536836009584.issue1625@psf.upfronthosting.co.za>


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


----------
resolution: accepted -> fixed

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

From report at bugs.python.org  Sun Jun  5 13:56:22 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 05 Jun 2011 11:56:22 +0000
Subject: [issue12265] revamp argument errors
In-Reply-To: <1307240443.69.0.736494632157.issue12265@psf.upfronthosting.co.za>
Message-ID: <1307274982.17.0.216451123537.issue12265@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/issue12265>
_______________________________________

From report at bugs.python.org  Sun Jun  5 14:57:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Jun 2011 12:57:58 +0000
Subject: [issue9972] PyGILState_XXX missing in Python builds without threads
In-Reply-To: <1285687340.14.0.296693885275.issue9972@psf.upfronthosting.co.za>
Message-ID: <1307278678.1.0.179709703611.issue9972@psf.upfronthosting.co.za>


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


----------
nosy: +haypo

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

From report at bugs.python.org  Sun Jun  5 15:15:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Jun 2011 13:15:44 +0000
Subject: [issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't
	batch function arguments by chunks
In-Reply-To: <1298300689.71.0.822605356721.issue11271@psf.upfronthosting.co.za>
Message-ID: <1307279744.72.0.238869941318.issue11271@psf.upfronthosting.co.za>


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

Using your test script fixed (on Python 3.3), I get the following numbers:

Starting multiproc...done in 2.1014609336853027 s.
Starting futures...done in 20.209479093551636 s.
Starting futures "fixed"...done in 2.026125907897949 s.

So there's a 0.2ms overhead per remote function call here (20/(100100000-100000000)).

Can't your chunks() function use itertools.islice()?

Also, the chunksize can't be anything else than 1 by default, since your approach is increasing latency of returning results.

----------
nosy: +pitrou
title: concurrent.futures.ProcessPoolExecutor.map() slower than multiprocessing.Pool.map() for fast function argument -> concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Sun Jun  5 15:18:54 2011
From: report at bugs.python.org (Tom Whittock)
Date: Sun, 05 Jun 2011 13:18:54 +0000
Subject: [issue12267] Difficult to compile python in Visual Studio 2010 express
In-Reply-To: <1307279934.45.0.187127370641.issue12267@psf.upfronthosting.co.za>
Message-ID: <1307279934.45.0.187127370641.issue12267@psf.upfronthosting.co.za>


New submission from Tom Whittock <tom.whittock at gmail.com>:

The automatic upgrade process included with Microsoft Visual Studio 2010 express is unable to deal with the project files in the python PC folder, due to it not supporting the x64 target. I had to manually edit the project files to remove all references to x64 before being able to upgrade the project. Included is a mercurial patch against the 2.7 line which adds project files for the 2010 express edition.

----------
components: Build
files: vs2010-express.patch
keywords: patch
messages: 137693
nosy: Tom.Whittock
priority: normal
severity: normal
status: open
title: Difficult to compile python in Visual Studio 2010 express
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file22255/vs2010-express.patch

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

From report at bugs.python.org  Sun Jun  5 15:28:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 05 Jun 2011 13:28:52 +0000
Subject: [issue12263] punycode codec ignores the error handler argument
In-Reply-To: <1307229378.45.0.142684435058.issue12263@psf.upfronthosting.co.za>
Message-ID: <1307280532.34.0.800376130887.issue12263@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/issue12263>
_______________________________________

From report at bugs.python.org  Sun Jun  5 15:37:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 05 Jun 2011 13:37:42 +0000
Subject: [issue12266] str.capitalize contradicts
In-Reply-To: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>
Message-ID: <1307281062.2.0.516635618911.issue12266@psf.upfronthosting.co.za>


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

This looks like a duplicate of #12204.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> str.upper converts to title

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

From report at bugs.python.org  Sun Jun  5 15:44:20 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 05 Jun 2011 13:44:20 +0000
Subject: [issue12267] Difficult to compile python in Visual Studio 2010 express
In-Reply-To: <1307279934.45.0.187127370641.issue12267@psf.upfronthosting.co.za>
Message-ID: <1307281460.2.0.427646454109.issue12267@psf.upfronthosting.co.za>


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

We don't currently support any flavor of VS2010.  Since 2.7 is in bug fix mode only, it is not clear that we will add such support.  But since it is a long term maintenance release the rules may be different.

----------
nosy: +brian.curtin, loewis, r.david.murray

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

From report at bugs.python.org  Sun Jun  5 15:49:17 2011
From: report at bugs.python.org (Tom Whittock)
Date: Sun, 05 Jun 2011 13:49:17 +0000
Subject: [issue12267] Difficult to compile python in Visual Studio 2010 express
In-Reply-To: <1307279934.45.0.187127370641.issue12267@psf.upfronthosting.co.za>
Message-ID: <1307281757.88.0.314322569353.issue12267@psf.upfronthosting.co.za>


Tom Whittock <tom.whittock at gmail.com> added the comment:

Fair enough. The reason I added it is because that's the most easily available free compiler for Windows machines at the moment, and due to the lack of x64 support it's not easy to start compiling python with it. It's quite awkward to get earlier express editions, and of course it costs money to get the pro edititons which would do the automatic upgrade with no trouble.

I could make you a 3.x patch for the same thing if you like? I happen to be using 2.7 at work so I just did what I needed.

----------

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

From report at bugs.python.org  Sun Jun  5 16:06:40 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 05 Jun 2011 14:06:40 +0000
Subject: [issue12267] Difficult to compile python in Visual Studio 2010 express
In-Reply-To: <1307279934.45.0.187127370641.issue12267@psf.upfronthosting.co.za>
Message-ID: <1307282800.67.0.68860146213.issue12267@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I have a fully working VS2010 build that I'm working on getting the ok to contribute from my employer. We may be able to use this for 3.3 but nothing earlier. I started a discussion on the Python-Dev list a few months ago but I don't believe we reached a consensus on supporting 2010 yet (IIRC).

----------

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

From report at bugs.python.org  Sun Jun  5 16:10:26 2011
From: report at bugs.python.org (Tom Whittock)
Date: Sun, 05 Jun 2011 14:10:26 +0000
Subject: [issue12267] Difficult to compile python in Visual Studio 2010 express
In-Reply-To: <1307279934.45.0.187127370641.issue12267@psf.upfronthosting.co.za>
Message-ID: <1307283026.34.0.519779288015.issue12267@psf.upfronthosting.co.za>


Tom Whittock <tom.whittock at gmail.com> added the comment:

Wouldn't a full (I assume you mean pro/team edition) 2010 version will include the x64 stuff which will make the express edition unable to load it?

----------

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

From report at bugs.python.org  Sun Jun  5 16:38:19 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 05 Jun 2011 14:38:19 +0000
Subject: [issue12267] Difficult to compile python in Visual Studio 2010 express
In-Reply-To: <1307279934.45.0.187127370641.issue12267@psf.upfronthosting.co.za>
Message-ID: <1307284699.77.0.598543471113.issue12267@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

We have to have x64 support, and the 2010 express version can now target x64 provided you have the x64 SDK installed. That wasn't true of 2008, but there were some registry/config file messing you could do in order to get x64 support out of 2008.

----------

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

From report at bugs.python.org  Sun Jun  5 17:00:43 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 05 Jun 2011 15:00:43 +0000
Subject: [issue12267] Difficult to compile python in Visual Studio 2010 express
In-Reply-To: <1307279934.45.0.187127370641.issue12267@psf.upfronthosting.co.za>
Message-ID: <1307286043.94.0.412963786742.issue12267@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Also, what I meant by "full" (in "fully working") in my message was that the full test suite passes. There are a number of code changes that have to be made, mostly around various constants used, e.g., in the socket module.

----------

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

From report at bugs.python.org  Sun Jun  5 17:06:55 2011
From: report at bugs.python.org (Tom Whittock)
Date: Sun, 05 Jun 2011 15:06:55 +0000
Subject: [issue12267] Difficult to compile python in Visual Studio 2010 express
In-Reply-To: <1307279934.45.0.187127370641.issue12267@psf.upfronthosting.co.za>
Message-ID: <1307286415.29.0.891456356892.issue12267@psf.upfronthosting.co.za>


Tom Whittock <tom.whittock at gmail.com> added the comment:

Ah, in that case it seems my patch isn't particularly useful then. I'd personally like to see Brian Curtins patch applied sooner rather than later, however - 2010 support is very important to me.

I'll be running that locally for the meantime, and I guess others could apply my patch if they find themselves in my situation also in the meantime.

I had no idea about the x64 support in express - useful info, thanks for that.

----------

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

From report at bugs.python.org  Sun Jun  5 17:29:01 2011
From: report at bugs.python.org (Michael Mulich)
Date: Sun, 05 Jun 2011 15:29:01 +0000
Subject: [issue10884] pkgutil EggInfoDistribution requirements for .egg-info
	metadata
In-Reply-To: <1294721787.13.0.963133670506.issue10884@psf.upfronthosting.co.za>
Message-ID: <1307287741.32.0.833869588354.issue10884@psf.upfronthosting.co.za>


Michael Mulich <michael.mulich at gmail.com> added the comment:

Looks like someone fixed this before distutils2 was merged into cpython as packaging. Thanks.

----------
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Sun Jun  5 17:40:55 2011
From: report at bugs.python.org (mike bayer)
Date: Sun, 05 Jun 2011 15:40:55 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1307288455.23.0.76803638165.issue7511@psf.upfronthosting.co.za>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

regarding "hey this is an MS bug not Python", projects which feature optional C extensions are starting to apply workarounds for the issue on their end (I will need to commit a specific catch for this to SQLAlchemy) - users need to install our software and we need to detect compilation failures as a sign to move on without it.   I think it's preferable for Python distutils to work around an MS issue rather than N projects having to work around an MS issue exposed through distutils.  Seems like this bug has been out there a real long time...bump ?

----------
nosy: +zzzeek

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

From report at bugs.python.org  Sun Jun  5 19:30:34 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 05 Jun 2011 17:30:34 +0000
Subject: [issue12134] json.dump much slower than dumps
In-Reply-To: <1305985086.83.0.259963774289.issue12134@psf.upfronthosting.co.za>
Message-ID: <1307295034.55.0.724870569018.issue12134@psf.upfronthosting.co.za>


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

With 'will try to ' and the next 'will ' omitted, I agree that Antoine's version is better than mine.

----------

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

From report at bugs.python.org  Sun Jun  5 19:54:50 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 05 Jun 2011 17:54:50 +0000
Subject: [issue12267] Difficult to compile python in Visual Studio 2010 express
In-Reply-To: <1307279934.45.0.187127370641.issue12267@psf.upfronthosting.co.za>
Message-ID: <1307296490.02.0.342566824772.issue12267@psf.upfronthosting.co.za>


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

I'm rejecting this patch - it's not the right approach to this problem.

If we want to support VS 2010 project files in some form, we should generate them out of the VS 2008 files, similar to the vs9to8 script. The conversion result should definitely support AMD64 builds - as Brian points out, VS 2010 *does* support AMD64, if the SDK is installed. 

Given that the automatic conversion works fairly well, though, I don't think anything needs to be done for 2.7 (except perhaps writing some documentation into PCbuild/readme.txt).

For 3.3, I would personally favor if Python would skip over VS 2010, and move right to VS 2012 (please don't discuss this aspect in this issue).

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Sun Jun  5 20:24:48 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 05 Jun 2011 18:24:48 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1307272971.79.0.274030994244.issue12021@psf.upfronthosting.co.za>
Message-ID: <20110605182444.GC1788@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

Antoine Pitrou wrote:
> I'm not sure about the original reason, but I find None as the default "omitted" value prettier than -1 myself, so I think it's a good thing :)

Yeah, and it's also good for consistency with other file-like objects.

Can I use _PyIO_ConvertSsize_t? Or should I duplicate its
functionality in mmapmodule.c?

----------

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

From report at bugs.python.org  Sun Jun  5 20:38:41 2011
From: report at bugs.python.org (poq)
Date: Sun, 05 Jun 2011 18:38:41 +0000
Subject: [issue12134] json.dump much slower than dumps
In-Reply-To: <1305985086.83.0.259963774289.issue12134@psf.upfronthosting.co.za>
Message-ID: <1307299121.07.0.0500894684233.issue12134@psf.upfronthosting.co.za>


poq <poq at gmx.com> added the comment:

dump() is not slower because it's incremental though. It's slower because it's pure Python. I don't think there is necessarily a memory/speed trade-off; it should be possible to write an incremental encoder in C as well.

----------

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

From report at bugs.python.org  Sun Jun  5 21:16:27 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 05 Jun 2011 19:16:27 +0000
Subject: [issue12246] create installation path if it's non-existent
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307301387.74.0.823054241597.issue12246@psf.upfronthosting.co.za>


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

I'm not sure I understand your confusion, but perhaps what you are missing is that we don't support installing 3rd party packages inside a source tree, only into an installed Python, and installing Python creates the site-packages directory in $prefix.

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

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

From report at bugs.python.org  Sun Jun  5 21:44:55 2011
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 05 Jun 2011 19:44:55 +0000
Subject: [issue12246] create installation path if it's non-existent
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307303095.11.0.46785173934.issue12246@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

Are there cases where my patch would result in site-packages directory installed in an unwanted place?

----------

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

From report at bugs.python.org  Sun Jun  5 21:54:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 05 Jun 2011 19:54:12 +0000
Subject: [issue12246] create installation path if it's non-existent
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307303652.34.0.556402075509.issue12246@psf.upfronthosting.co.za>


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

Yes.  If the directory gets created without Python being installed, then you don't have a working python installation.  Assuming we are talking about site-packages.  I have no idea what purelib is or anything about the packaging internals.

----------

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

From report at bugs.python.org  Sun Jun  5 22:15:48 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 05 Jun 2011 20:15:48 +0000
Subject: [issue12265] revamp argument errors
In-Reply-To: <1307240443.69.0.736494632157.issue12265@psf.upfronthosting.co.za>
Message-ID: <1307304948.2.0.552758402739.issue12265@psf.upfronthosting.co.za>


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

Your parenthetical reads sensibly to me, I can't think of a clearer alternative.

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

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

From report at bugs.python.org  Sun Jun  5 22:31:40 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 05 Jun 2011 20:31:40 +0000
Subject: [issue3771] test_httpservers intermittent failure, test_post and EINTR
In-Reply-To: <1220489239.6.0.433848845577.issue3771@psf.upfronthosting.co.za>
Message-ID: <1307305900.54.0.140225173059.issue3771@psf.upfronthosting.co.za>


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

This was fixed in the other bug in 2.6 and 2.7.

----------
dependencies: +socket.readline() interface doesn't handle EINTR properly
nosy: +gregory.p.smith
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Jun  5 22:39:04 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 05 Jun 2011 20:39:04 +0000
Subject: [issue12268] file readline & readlines methods can lose data on EINTR
In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za>
Message-ID: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za>


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

The file object readline() and readlines() methods can lose data when an underlying read system call is interrupted.  They will abort with an IOError in this case but any incomplete line data they have read will be discarded.

readline() and readlines() should never raise an IOError for the EINTR interrupted system call case.  They should handle that gracefully, retrying their reads after letting any Python signal handlers run.

----------
assignee: gregory.p.smith
files: file-signal-eintr-27.diff
keywords: needs review, patch
messages: 137714
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: file readline & readlines methods can lose data on EINTR
versions: Python 2.7
Added file: http://bugs.python.org/file22258/file-signal-eintr-27.diff

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

From report at bugs.python.org  Sun Jun  5 22:39:31 2011
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 05 Jun 2011 20:39:31 +0000
Subject: [issue12246] create installation path if it's non-existent
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307306371.95.0.334274822282.issue12246@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

I've changed the patch to represent what I've since learned. It now just displays a message, instead of silently creating the missing path.

----------
Added file: http://bugs.python.org/file22259/display-warning.diff

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

From report at bugs.python.org  Sun Jun  5 21:55:45 2011
From: report at bugs.python.org (David Watson)
Date: Sun, 05 Jun 2011 19:55:45 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1306811332.95.0.283776934259.issue6560@psf.upfronthosting.co.za>
Message-ID: <20110605195325.GA12959@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

On Tue 31 May 2011, Brian May wrote:
> Also had a half-hearted attempt at porting to Python 2.7, but
> didn't get past compiling, the code requires BEGIN_SELECT_LOOP
> and END_SELECT_LOOP macros that aren't defined in Python 2.7 -
> I tried copying the definitions from Python 3.3, but that
> didn't work either. Not sure if it is worth the effort if
> Python 2.7 is closed to new features.

Well, if it's any use to anyone, here is a backport to 2.x (the
*_SELECT_LOOP macros aren't important, and it's otherwise
straightforward).

Also attaching a new 3.x patch which fixes some deprecated markup
in the docs and adds the send/recvmsg() methods to
test_wrapped_unconnected() in test_ssl.py.

----------
Added file: http://bugs.python.org/file22256/baikie-hwundram-v6.diff
Added file: http://bugs.python.org/file22257/baikie-hwundram-v6-for-2.x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________
-------------- next part --------------
# HG changeset patch
# User David Watson <vcs at dbwatson.ukfsn.org>, Heiko Wundram
# Date 1307302911 -3600
# Node ID eb5f9eadf9b75bb9494e201458df10f94420ad94
# Parent  7323a865457a12711d68f9ba1bae21978b513955
Issue #6560: support sendmsg() and recvmsg() on sockets.
Patch by David Watson and Heiko Wundram.

diff --git a/Doc/library/socket.rst b/Doc/library/socket.rst
--- a/Doc/library/socket.rst
+++ b/Doc/library/socket.rst
@@ -198,6 +198,7 @@ The module :mod:`socket` exports the fol
           SOMAXCONN
           MSG_*
           SOL_*
+          SCM_*
           IPPROTO_*
           IPPORT_*
           INADDR_*
@@ -511,6 +512,49 @@ The module :mod:`socket` exports the fol
    Availability: Unix (maybe not all platforms).
 
 
+..
+   XXX: Are sendmsg(), recvmsg() and CMSG_*() available on any
+   non-Unix platforms?  The old (obsolete?) 4.2BSD form of the
+   interface, in which struct msghdr has no msg_control or
+   msg_controllen members, is not currently supported.
+
+.. function:: CMSG_LEN(length)
+
+   Return the total length, without trailing padding, of an ancillary
+   data item with associated data of the given *length*.  This value
+   can often be used as the buffer size for :meth:`~socket.recvmsg` to
+   receive a single item of ancillary data, but :rfc:`3542` requires
+   portable applications to use :func:`CMSG_SPACE` and thus include
+   space for padding, even when the item will be the last in the
+   buffer.  Raises :exc:`OverflowError` if *length* is outside the
+   permissible range of values.
+
+   Availability: most Unix platforms, possibly others.
+
+   .. versionadded:: XXX
+
+
+.. function:: CMSG_SPACE(length)
+
+   Return the buffer size needed for :meth:`~socket.recvmsg` to
+   receive an ancillary data item with associated data of the given
+   *length*, along with any trailing padding.  The buffer space needed
+   to receive multiple items is the sum of the :func:`CMSG_SPACE`
+   values for their associated data lengths.  Raises
+   :exc:`OverflowError` if *length* is outside the permissible range
+   of values.
+
+   Note that some systems might support ancillary data without
+   providing this function.  Also note that setting the buffer size
+   using the results of this function may not precisely limit the
+   amount of ancillary data that can be received, since additional
+   data may be able to fit into the padding area.
+
+   Availability: most Unix platforms, possibly others.
+
+   .. versionadded:: XXX
+
+
 .. function:: getdefaulttimeout()
 
    Return the default timeout in floating seconds for new socket objects. A value
@@ -742,6 +786,109 @@ correspond to Unix system calls applicab
    to zero. (The format of *address* depends on the address family --- see above.)
 
 
+.. method:: socket.recvmsg(bufsize[, ancbufsize[, flags]])
+
+   Receive normal data (up to *bufsize* bytes) and ancillary data from
+   the socket.  The *ancbufsize* argument sets the size in bytes of
+   the internal buffer used to receive the ancillary data; it defaults
+   to 0, meaning that no ancillary data will be received.  Appropriate
+   buffer sizes for ancillary data can be calculated using
+   :func:`CMSG_SPACE` or :func:`CMSG_LEN`, and items which do not fit
+   into the buffer might be truncated or discarded.  The *flags*
+   argument defaults to 0 and has the same meaning as for
+   :meth:`recv`.
+
+   The return value is a 4-tuple: ``(data, ancdata, msg_flags,
+   address)``.  The *data* item is a :class:`bytes` object holding the
+   non-ancillary data received.  The *ancdata* item is a list of zero
+   or more tuples ``(cmsg_level, cmsg_type, cmsg_data)`` representing
+   the ancillary data (control messages) received: *cmsg_level* and
+   *cmsg_type* are integers specifying the protocol level and
+   protocol-specific type respectively, and *cmsg_data* is a
+   :class:`bytes` object holding the associated data.  The *msg_flags*
+   item is the bitwise OR of various flags indicating conditions on
+   the received message; see your system documentation for details.
+   If the receiving socket is unconnected, *address* is the address of
+   the sending socket, if available; otherwise, its value is
+   unspecified.
+
+   On some systems, :meth:`sendmsg` and :meth:`recvmsg` can be used to
+   pass file descriptors between processes over an :const:`AF_UNIX`
+   socket.  When this facility is used (it is often restricted to
+   :const:`SOCK_STREAM` sockets), :meth:`recvmsg` will return, in its
+   ancillary data, items of the form ``(socket.SOL_SOCKET,
+   socket.SCM_RIGHTS, fds)``, where *fds* is a :class:`bytes` object
+   representing the new file descriptors as a binary array of the
+   native C :c:type:`int` type.  If :meth:`recvmsg` raises an
+   exception after the system call returns, it will first attempt to
+   close any file descriptors received via this mechanism.
+
+   Some systems do not indicate the truncated length of ancillary data
+   items which have been only partially received.  If an item appears
+   to extend beyond the end of the buffer, :meth:`recvmsg` will issue
+   a :exc:`RuntimeWarning`, and will return the part of it which is
+   inside the buffer provided it has not been truncated before the
+   start of its associated data.
+
+   On systems which support the :const:`SCM_RIGHTS` mechanism, the
+   following function will receive up to *maxfds* file descriptors,
+   returning the message data and a list containing the descriptors
+   (while ignoring unexpected conditions such as unrelated control
+   messages being received).  See also :meth:`sendmsg`. ::
+
+      import socket, array
+
+      def recv_fds(sock, msglen, maxfds):
+          fds = array.array("i")   # Array of ints
+          msg, ancdata, flags, addr = sock.recvmsg(msglen, socket.CMSG_LEN(maxfds * fds.itemsize))
+          for cmsg_level, cmsg_type, cmsg_data in ancdata:
+              if (cmsg_level == socket.SOL_SOCKET and cmsg_type == socket.SCM_RIGHTS):
+                  # Append data, ignoring any truncated integers at the end.
+                  fds.fromstring(cmsg_data[:len(cmsg_data) - (len(cmsg_data) % fds.itemsize)])
+          return msg, list(fds)
+
+   Availability: most Unix platforms, possibly others.
+
+   .. versionadded:: XXX
+
+
+.. method:: socket.recvmsg_into(buffers[, ancbufsize[, flags]])
+
+   Receive normal data and ancillary data from the socket, behaving as
+   :meth:`recvmsg` would, but scatter the non-ancillary data into a
+   series of buffers instead of returning a new bytes object.  The
+   *buffers* argument must be an iterable of objects that export
+   writable buffers (e.g. :class:`bytearray` objects); these will be
+   filled with successive chunks of the non-ancillary data until it
+   has all been written or there are no more buffers.  The operating
+   system may set a limit (:func:`~os.sysconf` value ``SC_IOV_MAX``)
+   on the number of buffers that can be used.  The *ancbufsize* and
+   *flags* arguments have the same meaning as for :meth:`recvmsg`.
+
+   The return value is a 4-tuple: ``(nbytes, ancdata, msg_flags,
+   address)``, where *nbytes* is the total number of bytes of
+   non-ancillary data written into the buffers, and *ancdata*,
+   *msg_flags* and *address* are the same as for :meth:`recvmsg`.
+
+   Example::
+
+      >>> import socket
+      >>> s1, s2 = socket.socketpair()
+      >>> b1 = bytearray(b'----')
+      >>> b2 = bytearray(b'0123456789')
+      >>> b3 = bytearray(b'--------------')
+      >>> s1.send(b'Mary had a little lamb')
+      22
+      >>> s2.recvmsg_into([b1, memoryview(b2)[2:9], b3])
+      (22, [], 0, None)
+      >>> [b1, b2, b3]
+      [bytearray(b'Mary'), bytearray(b'01 had a 9'), bytearray(b'little lamb---')]
+
+   Availability: most Unix platforms, possibly others.
+
+   .. versionadded:: XXX
+
+
 .. method:: socket.recvfrom_into(buffer[, nbytes[, flags]])
 
    Receive data from the socket, writing it into *buffer* instead of creating a
@@ -789,6 +936,41 @@ correspond to Unix system calls applicab
    above.)
 
 
+.. method:: socket.sendmsg(buffers[, ancdata[, flags[, address]]])
+
+   Send normal and ancillary data to the socket, gathering the
+   non-ancillary data from a series of buffers and concatenating it
+   into a single message.  The *buffers* argument specifies the
+   non-ancillary data as an iterable of buffer-compatible objects
+   (e.g. :class:`bytes` objects); the operating system may set a limit
+   (:func:`~os.sysconf` value ``SC_IOV_MAX``) on the number of buffers
+   that can be used.  The *ancdata* argument specifies the ancillary
+   data (control messages) as an iterable of zero or more tuples
+   ``(cmsg_level, cmsg_type, cmsg_data)``, where *cmsg_level* and
+   *cmsg_type* are integers specifying the protocol level and
+   protocol-specific type respectively, and *cmsg_data* is a
+   buffer-compatible object holding the associated data.  Note that
+   some systems (in particular, systems without :func:`CMSG_SPACE`)
+   might support sending only one control message per call.  The
+   *flags* argument defaults to 0 and has the same meaning as for
+   :meth:`send`.  If *address* is supplied and not ``None``, it sets a
+   destination address for the message.  The return value is the
+   number of bytes of non-ancillary data sent.
+
+   The following function sends the list of file descriptors *fds*
+   over an :const:`AF_UNIX` socket, on systems which support the
+   :const:`SCM_RIGHTS` mechanism.  See also :meth:`recvmsg`. ::
+
+      import socket, array
+
+      def send_fds(sock, msg, fds):
+          return sock.sendmsg([msg], [(socket.SOL_SOCKET, socket.SCM_RIGHTS, array.array("i", fds))])
+
+   Availability: most Unix platforms, possibly others.
+
+   .. versionadded:: XXX
+
+
 .. method:: socket.setblocking(flag)
 
    Set blocking or non-blocking mode of the socket: if *flag* is false, the
diff --git a/Lib/ssl.py b/Lib/ssl.py
--- a/Lib/ssl.py
+++ b/Lib/ssl.py
@@ -349,6 +349,14 @@ class SSLSocket(socket):
         else:
             return socket.sendto(self, data, flags_or_addr, addr)
 
+    def sendmsg(self, *args, **kwargs):
+        self._checkClosed()
+        if self._sslobj:
+            raise ValueError("sendmsg not allowed on instances of %s" %
+                             self.__class__)
+        else:
+            return socket.sendmsg(self, *args, **kwargs)
+
     def sendall(self, data, flags=0):
         self._checkClosed()
         if self._sslobj:
@@ -407,6 +415,22 @@ class SSLSocket(socket):
         else:
             return socket.recvfrom_into(self, buffer, nbytes, flags)
 
+    def recvmsg(self, *args, **kwargs):
+        self._checkClosed()
+        if self._sslobj:
+            raise ValueError("recvmsg not allowed on instances of %s" %
+                             self.__class__)
+        else:
+            return socket.recvmsg(self, *args, **kwargs)
+
+    def recvmsg_into(self, *args, **kwargs):
+        self._checkClosed()
+        if self._sslobj:
+            raise ValueError("recvmsg_into not allowed on instances of %s" %
+                             self.__class__)
+        else:
+            return socket.recvmsg_into(self, *args, **kwargs)
+
     def pending(self):
         self._checkClosed()
         if self._sslobj:
diff --git a/Lib/test/test_socket.py b/Lib/test/test_socket.py
--- a/Lib/test/test_socket.py
+++ b/Lib/test/test_socket.py
@@ -7,6 +7,8 @@ import errno
 import io
 import socket
 import select
+import tempfile
+import _testcapi
 import time
 import traceback
 import queue
@@ -34,6 +36,9 @@ except ImportError:
     thread = None
     threading = None
 
+# Size in bytes of the int type
+SIZEOF_INT = array.array("i").itemsize
+
 class SocketTCPTest(unittest.TestCase):
 
     def setUp(self):
@@ -55,6 +60,26 @@ class SocketUDPTest(unittest.TestCase):
         self.serv.close()
         self.serv = None
 
+class ThreadSafeCleanupTestCase(unittest.TestCase):
+    """Subclass of unittest.TestCase with thread-safe cleanup methods.
+
+    This subclass protects the addCleanup() and doCleanups() methods
+    with a recursive lock.
+    """
+
+    if threading:
+        def __init__(self, *args, **kwargs):
+            super().__init__(*args, **kwargs)
+            self._cleanup_lock = threading.RLock()
+
+        def addCleanup(self, *args, **kwargs):
+            with self._cleanup_lock:
+                return super().addCleanup(*args, **kwargs)
+
+        def doCleanups(self, *args, **kwargs):
+            with self._cleanup_lock:
+                return super().doCleanups(*args, **kwargs)
+
 class ThreadableTest:
     """Threadable Test class
 
@@ -237,6 +262,243 @@ class SocketPairTest(unittest.TestCase, 
         ThreadableTest.clientTearDown(self)
 
 
+# The following classes are used by the sendmsg()/recvmsg() tests.
+# Combining, for instance, ConnectedStreamTestMixin and TCPTestBase
+# gives a drop-in replacement for SocketConnectedTest, but different
+# address families can be used, and the attributes serv_addr and
+# cli_addr will be set to the addresses of the endpoints.
+
+class SocketTestBase(unittest.TestCase):
+    """A base class for socket tests.
+
+    Subclasses must provide methods newSocket() to return a new socket
+    and bindSock(sock) to bind it to an unused address.
+
+    Creates a socket self.serv and sets self.serv_addr to its address.
+    """
+
+    def setUp(self):
+        self.serv = self.newSocket()
+        self.bindServer()
+
+    def bindServer(self):
+        """Bind server socket and set self.serv_addr to its address."""
+        self.bindSock(self.serv)
+        self.serv_addr = self.serv.getsockname()
+
+    def tearDown(self):
+        self.serv.close()
+        self.serv = None
+
+
+class SocketListeningTestMixin(SocketTestBase):
+    """Mixin to listen on the server socket."""
+
+    def setUp(self):
+        super().setUp()
+        self.serv.listen(1)
+
+
+class ThreadedSocketTestMixin(ThreadSafeCleanupTestCase, SocketTestBase,
+                              ThreadableTest):
+    """Mixin to add client socket and allow client/server tests.
+
+    Client socket is self.cli and its address is self.cli_addr.  See
+    ThreadableTest for usage information.
+    """
+
+    def __init__(self, *args, **kwargs):
+        super().__init__(*args, **kwargs)
+        ThreadableTest.__init__(self)
+
+    def clientSetUp(self):
+        self.cli = self.newClientSocket()
+        self.bindClient()
+
+    def newClientSocket(self):
+        """Return a new socket for use as client."""
+        return self.newSocket()
+
+    def bindClient(self):
+        """Bind client socket and set self.cli_addr to its address."""
+        self.bindSock(self.cli)
+        self.cli_addr = self.cli.getsockname()
+
+    def clientTearDown(self):
+        self.cli.close()
+        self.cli = None
+        ThreadableTest.clientTearDown(self)
+
+
+class ConnectedStreamTestMixin(SocketListeningTestMixin,
+                               ThreadedSocketTestMixin):
+    """Mixin to allow client/server stream tests with connected client.
+
+    Server's socket representing connection to client is self.cli_conn
+    and client's connection to server is self.serv_conn.  (Based on
+    SocketConnectedTest.)
+    """
+
+    def setUp(self):
+        super().setUp()
+        # Indicate explicitly we're ready for the client thread to
+        # proceed and then perform the blocking call to accept
+        self.serverExplicitReady()
+        conn, addr = self.serv.accept()
+        self.cli_conn = conn
+
+    def tearDown(self):
+        self.cli_conn.close()
+        self.cli_conn = None
+        super().tearDown()
+
+    def clientSetUp(self):
+        super().clientSetUp()
+        self.cli.connect(self.serv_addr)
+        self.serv_conn = self.cli
+
+    def clientTearDown(self):
+        self.serv_conn.close()
+        self.serv_conn = None
+        super().clientTearDown()
+
+
+class UnixSocketTestBase(SocketTestBase):
+    """Base class for Unix-domain socket tests."""
+
+    # This class is used for file descriptor passing tests, so we
+    # create the sockets in a private directory so that other users
+    # can't send anything that might be problematic for a privileged
+    # user running the tests.
+
+    def setUp(self):
+        self.dir_path = tempfile.mkdtemp()
+        self.addCleanup(os.rmdir, self.dir_path)
+        super().setUp()
+
+    def bindSock(self, sock):
+        path = tempfile.mktemp(dir=self.dir_path)
+        sock.bind(path)
+        self.addCleanup(support.unlink, path)
+
+class UnixStreamBase(UnixSocketTestBase):
+    """Base class for Unix-domain SOCK_STREAM tests."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
+
+
+class InetTestBase(SocketTestBase):
+    """Base class for IPv4 socket tests."""
+
+    host = HOST
+
+    def setUp(self):
+        super().setUp()
+        self.port = self.serv_addr[1]
+
+    def bindSock(self, sock):
+        support.bind_port(sock, host=self.host)
+
+class TCPTestBase(InetTestBase):
+    """Base class for TCP-over-IPv4 tests."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+
+class UDPTestBase(InetTestBase):
+    """Base class for UDP-over-IPv4 tests."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
+
+class SCTPStreamBase(InetTestBase):
+    """Base class for SCTP tests in one-to-one (SOCK_STREAM) mode."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_INET, socket.SOCK_STREAM,
+                             socket.IPPROTO_SCTP)
+
+
+class Inet6TestBase(InetTestBase):
+    """Base class for IPv6 socket tests."""
+
+    # Don't use "localhost" here - it may not have an IPv6 address
+    # assigned to it by default (e.g. in /etc/hosts), and if someone
+    # has assigned it an IPv4-mapped address, then it's unlikely to
+    # work with the full IPv6 API.
+    host = "::1"
+
+class UDP6TestBase(Inet6TestBase):
+    """Base class for UDP-over-IPv6 tests."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
+
+
+# Test-skipping decorators for use with ThreadableTest.
+
+def skipWithClientIf(condition, reason):
+    """Skip decorated test if condition is true, add client_skip decorator.
+
+    If the decorated object is not a class, sets its attribute
+    "client_skip" to a decorator which will return an empty function
+    if the test is to be skipped, or the original function if it is
+    not.  This can be used to avoid running the client part of a
+    skipped test when using ThreadableTest.
+    """
+    def client_pass(*args, **kwargs):
+        pass
+    def skipdec(obj):
+        retval = unittest.skip(reason)(obj)
+        if not isinstance(obj, type):
+            retval.client_skip = lambda f: client_pass
+        return retval
+    def noskipdec(obj):
+        if not (isinstance(obj, type) or hasattr(obj, "client_skip")):
+            obj.client_skip = lambda f: f
+        return obj
+    return skipdec if condition else noskipdec
+
+
+def requireAttrs(obj, *attributes):
+    """Skip decorated test if obj is missing any of the given attributes.
+
+    Sets client_skip attribute as skipWithClientIf() does.
+    """
+    missing = [name for name in attributes if not hasattr(obj, name)]
+    return skipWithClientIf(
+        missing, "don't have " + ", ".join(name for name in missing))
+
+
+def requireSocket(*args):
+    """Skip decorated test if a socket cannot be created with given arguments.
+
+    When an argument is given as a string, will use the value of that
+    attribute of the socket module, or skip the test if it doesn't
+    exist.  Sets client_skip attribute as skipWithClientIf() does.
+    """
+    err = None
+    missing = [obj for obj in args if
+               isinstance(obj, str) and not hasattr(socket, obj)]
+    if missing:
+        err = "don't have " + ", ".join(name for name in missing)
+    else:
+        callargs = [getattr(socket, obj) if isinstance(obj, str) else obj
+                    for obj in args]
+        try:
+            s = socket.socket(*callargs)
+        except socket.error as e:
+            # XXX: check errno?
+            err = str(e)
+        else:
+            s.close()
+    return skipWithClientIf(
+        err is not None,
+        "can't create socket({0}): {1}".format(
+            ", ".join(str(o) for o in args), err))
+
+
 #######################################################################
 ## Begin Tests
 
@@ -947,6 +1209,1839 @@ class BasicUDPTest(ThreadedUDPSocketTest
     def _testRecvFromNegative(self):
         self.cli.sendto(MSG, 0, (HOST, self.port))
 
+
+# Tests for the sendmsg()/recvmsg() interface.  Where possible, the
+# same test code is used with different families and types of socket
+# (e.g. stream, datagram), and tests using recvmsg() are repeated
+# using recvmsg_into().
+#
+# The generic test classes such as SendmsgTests and
+# RecvmsgGenericTests inherit from SendrecvmsgBase and expect to be
+# supplied with sockets cli_sock and serv_sock representing the
+# client's and the server's end of the connection respectively, and
+# attributes cli_addr and serv_addr holding their (numeric where
+# appropriate) addresses.
+#
+# The final concrete test classes combine these with subclasses of
+# SocketTestBase which set up client and server sockets of a specific
+# type, and with subclasses of SendrecvmsgBase such as
+# SendrecvmsgDgramBase and SendrecvmsgConnectedBase which map these
+# sockets to cli_sock and serv_sock and override the methods and
+# attributes of SendrecvmsgBase to fill in destination addresses if
+# needed when sending, check for specific flags in msg_flags, etc.
+#
+# RecvmsgIntoMixin provides a version of doRecvmsg() implemented using
+# recvmsg_into().
+
+# XXX: like the other datagram (UDP) tests in this module, the code
+# here assumes that datagram delivery on the local machine will be
+# reliable.
+
+class SendrecvmsgBase(ThreadSafeCleanupTestCase):
+    # Base class for sendmsg()/recvmsg() tests.
+
+    # Time in seconds to wait before considering a test failed, or
+    # None for no timeout.  Not all tests actually set a timeout.
+    fail_timeout = 3.0
+
+    def setUp(self):
+        self.misc_event = threading.Event()
+        super().setUp()
+
+    def sendToServer(self, msg):
+        # Send msg to the server.
+        return self.cli_sock.send(msg)
+
+    # Tuple of alternative default arguments for sendmsg() when called
+    # via sendmsgToServer() (e.g. to include a destination address).
+    sendmsg_to_server_defaults = ()
+
+    def sendmsgToServer(self, *args):
+        # Call sendmsg() on self.cli_sock with the given arguments,
+        # filling in any arguments which are not supplied with the
+        # corresponding items of self.sendmsg_to_server_defaults, if
+        # any.
+        return self.cli_sock.sendmsg(
+            *(args + self.sendmsg_to_server_defaults[len(args):]))
+
+    def doRecvmsg(self, sock, bufsize, *args):
+        # Call recvmsg() on sock with given arguments and return its
+        # result.  Should be used for tests which can use either
+        # recvmsg() or recvmsg_into() - RecvmsgIntoMixin overrides
+        # this method with one which emulates it using recvmsg_into(),
+        # thus allowing the same test to be used for both methods.
+        result = sock.recvmsg(bufsize, *args)
+        self.registerRecvmsgResult(result)
+        return result
+
+    def registerRecvmsgResult(self, result):
+        # Called by doRecvmsg() with the return value of recvmsg() or
+        # recvmsg_into().  Can be overridden to arrange cleanup based
+        # on the returned ancillary data, for instance.
+        pass
+
+    def checkRecvmsgAddress(self, addr1, addr2):
+        # Called to compare the received address with the address of
+        # the peer.
+        self.assertEqual(addr1, addr2)
+
+    # Flags that are normally unset in msg_flags
+    msg_flags_common_unset = 0
+    for name in ("MSG_CTRUNC", "MSG_OOB"):
+        msg_flags_common_unset |= getattr(socket, name, 0)
+
+    # Flags that are normally set
+    msg_flags_common_set = 0
+
+    # Flags set when a complete record has been received (e.g. MSG_EOR
+    # for SCTP)
+    msg_flags_eor_indicator = 0
+
+    # Flags set when a complete record has not been received
+    # (e.g. MSG_TRUNC for datagram sockets)
+    msg_flags_non_eor_indicator = 0
+
+    def checkFlags(self, flags, eor=None, checkset=0, checkunset=0, ignore=0):
+        # Method to check the value of msg_flags returned by recvmsg[_into]().
+        #
+        # Checks that all bits in msg_flags_common_set attribute are
+        # set in "flags" and all bits in msg_flags_common_unset are
+        # unset.
+        #
+        # The "eor" argument specifies whether the flags should
+        # indicate that a full record (or datagram) has been received.
+        # If "eor" is None, no checks are done; otherwise, checks
+        # that:
+        #
+        #  * if "eor" is true, all bits in msg_flags_eor_indicator are
+        #    set and all bits in msg_flags_non_eor_indicator are unset
+        #
+        #  * if "eor" is false, all bits in msg_flags_non_eor_indicator
+        #    are set and all bits in msg_flags_eor_indicator are unset
+        #
+        # If "checkset" and/or "checkunset" are supplied, they require
+        # the given bits to be set or unset respectively, overriding
+        # what the attributes require for those bits.
+        #
+        # If any bits are set in "ignore", they will not be checked,
+        # regardless of the other inputs.
+        #
+        # Will raise Exception if the inputs require a bit to be both
+        # set and unset, and it is not ignored.
+
+        defaultset = self.msg_flags_common_set
+        defaultunset = self.msg_flags_common_unset
+
+        if eor:
+            defaultset |= self.msg_flags_eor_indicator
+            defaultunset |= self.msg_flags_non_eor_indicator
+        elif eor is not None:
+            defaultset |= self.msg_flags_non_eor_indicator
+            defaultunset |= self.msg_flags_eor_indicator
+
+        # Function arguments override defaults
+        defaultset &= ~checkunset
+        defaultunset &= ~checkset
+
+        # Merge arguments with remaining defaults, and check for conflicts
+        checkset |= defaultset
+        checkunset |= defaultunset
+        inboth = checkset & checkunset & ~ignore
+        if inboth:
+            raise Exception("contradictory set, unset requirements for flags "
+                            "{0:#x}".format(inboth))
+
+        # Compare with given msg_flags value
+        mask = (checkset | checkunset) & ~ignore
+        self.assertEqual(flags & mask, checkset & mask)
+
+
+class RecvmsgIntoMixin(SendrecvmsgBase):
+    # Mixin to implement doRecvmsg() using recvmsg_into().
+
+    def doRecvmsg(self, sock, bufsize, *args):
+        buf = bytearray(bufsize)
+        result = sock.recvmsg_into([buf], *args)
+        self.registerRecvmsgResult(result)
+        self.assertGreaterEqual(result[0], 0)
+        self.assertLessEqual(result[0], bufsize)
+        return (bytes(buf[:result[0]]),) + result[1:]
+
+
+class SendrecvmsgDgramFlagsBase(SendrecvmsgBase):
+    # Defines flags to be checked in msg_flags for datagram sockets.
+
+    @property
+    def msg_flags_non_eor_indicator(self):
+        return super().msg_flags_non_eor_indicator | socket.MSG_TRUNC
+
+
+class SendrecvmsgSCTPFlagsBase(SendrecvmsgBase):
+    # Defines flags to be checked in msg_flags for SCTP sockets.
+
+    @property
+    def msg_flags_eor_indicator(self):
+        return super().msg_flags_eor_indicator | socket.MSG_EOR
+
+
+class SendrecvmsgConnectionlessBase(SendrecvmsgBase):
+    # Base class for tests on connectionless-mode sockets.  Users must
+    # supply sockets on attributes cli and serv to be mapped to
+    # cli_sock and serv_sock respectively.
+
+    @property
+    def serv_sock(self):
+        return self.serv
+
+    @property
+    def cli_sock(self):
+        return self.cli
+
+    @property
+    def sendmsg_to_server_defaults(self):
+        return ([], [], 0, self.serv_addr)
+
+    def sendToServer(self, msg):
+        return self.cli_sock.sendto(msg, self.serv_addr)
+
+
+class SendrecvmsgConnectedBase(SendrecvmsgBase):
+    # Base class for tests on connected sockets.  Users must supply
+    # sockets on attributes serv_conn and cli_conn (representing the
+    # connections *to* the server and the client), to be mapped to
+    # cli_sock and serv_sock respectively.
+
+    @property
+    def serv_sock(self):
+        return self.cli_conn
+
+    @property
+    def cli_sock(self):
+        return self.serv_conn
+
+    def checkRecvmsgAddress(self, addr1, addr2):
+        # Address is currently "unspecified" for a connected socket,
+        # so we don't examine it
+        pass
+
+
+class SendrecvmsgServerTimeoutBase(SendrecvmsgBase):
+    # Base class to set a timeout on server's socket.
+
+    def setUp(self):
+        super().setUp()
+        self.serv_sock.settimeout(self.fail_timeout)
+
+
+class SendmsgTests(SendrecvmsgServerTimeoutBase):
+    # Tests for sendmsg() which can use any socket type and do not
+    # involve recvmsg() or recvmsg_into().
+
+    def testSendmsg(self):
+        # Send a simple message with sendmsg().
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsg(self):
+        self.assertEqual(self.sendmsgToServer([MSG]), len(MSG))
+
+    def testSendmsgDataGenerator(self):
+        # Send from buffer obtained from a generator (not a sequence).
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgDataGenerator(self):
+        self.assertEqual(self.sendmsgToServer((o for o in [MSG])),
+                         len(MSG))
+
+    def testSendmsgAncillaryGenerator(self):
+        # Gather (empty) ancillary data from a generator.
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgAncillaryGenerator(self):
+        self.assertEqual(self.sendmsgToServer([MSG], (o for o in [])),
+                         len(MSG))
+
+    def testSendmsgArray(self):
+        # Send data from an array instead of the usual bytes object.
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgArray(self):
+        self.assertEqual(self.sendmsgToServer([array.array("B", MSG)]),
+                         len(MSG))
+
+    def testSendmsgGather(self):
+        # Send message data from more than one buffer (gather write).
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgGather(self):
+        self.assertEqual(self.sendmsgToServer([MSG[:3], MSG[3:]]), len(MSG))
+
+    def testSendmsgBadArgs(self):
+        # Check that sendmsg() rejects invalid arguments.
+        self.assertEqual(self.serv_sock.recv(1000), b"done")
+
+    def _testSendmsgBadArgs(self):
+        self.assertRaises(TypeError, self.cli_sock.sendmsg)
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          b"not in an iterable")
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          object())
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [object()])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG, object()])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], object())
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [], object())
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [], 0, object())
+        self.sendToServer(b"done")
+
+    def testSendmsgBadCmsg(self):
+        # Check that invalid ancillary data items are rejected.
+        self.assertEqual(self.serv_sock.recv(1000), b"done")
+
+    def _testSendmsgBadCmsg(self):
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [object()])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(object(), 0, b"data")])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, object(), b"data")])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, 0, object())])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, 0)])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, 0, b"data", 42)])
+        self.sendToServer(b"done")
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testSendmsgBadMultiCmsg(self):
+        # Check that invalid ancillary data items are rejected when
+        # more than one item is present.
+        self.assertEqual(self.serv_sock.recv(1000), b"done")
+
+    @testSendmsgBadMultiCmsg.client_skip
+    def _testSendmsgBadMultiCmsg(self):
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [0, 0, b""])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, 0, b""), object()])
+        self.sendToServer(b"done")
+
+    def testSendmsgExcessCmsgReject(self):
+        # Check that sendmsg() rejects excess ancillary data items
+        # when the number that can be sent is limited.
+        self.assertEqual(self.serv_sock.recv(1000), b"done")
+
+    def _testSendmsgExcessCmsgReject(self):
+        if not hasattr(socket, "CMSG_SPACE"):
+            # Can only send one item
+            with self.assertRaises(socket.error) as cm:
+                self.sendmsgToServer([MSG], [(0, 0, b""), (0, 0, b"")])
+            self.assertIsNone(cm.exception.errno)
+        self.sendToServer(b"done")
+
+    def testSendmsgAfterClose(self):
+        # Check that sendmsg() fails on a closed socket.
+        pass
+
+    def _testSendmsgAfterClose(self):
+        self.cli_sock.close()
+        self.assertRaises(socket.error, self.sendmsgToServer, [MSG])
+
+
+class SendmsgStreamTests(SendmsgTests):
+    # Tests for sendmsg() which require a stream socket and do not
+    # involve recvmsg() or recvmsg_into().
+
+    def testSendmsgExplicitNoneAddr(self):
+        # Check that peer address can be specified as None.
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgExplicitNoneAddr(self):
+        self.assertEqual(self.sendmsgToServer([MSG], [], 0, None), len(MSG))
+
+    def testSendmsgTimeout(self):
+        # Check that timeout works with sendmsg().
+        self.assertEqual(self.serv_sock.recv(512), b"a"*512)
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+
+    def _testSendmsgTimeout(self):
+        try:
+            self.cli_sock.settimeout(0.03)
+            with self.assertRaises(socket.timeout):
+                while True:
+                    self.sendmsgToServer([b"a"*512])
+        finally:
+            self.misc_event.set()
+
+    # XXX: would be nice to have more tests for sendmsg flags argument.
+
+    # Linux supports MSG_DONTWAIT when sending, but in general, it
+    # only works when receiving.  Could add other platforms if they
+    # support it too.
+    @skipWithClientIf(sys.platform not in {"linux2"},
+                      "MSG_DONTWAIT not known to work on this platform when "
+                      "sending")
+    def testSendmsgDontWait(self):
+        # Check that MSG_DONTWAIT in flags causes non-blocking behaviour.
+        self.assertEqual(self.serv_sock.recv(512), b"a"*512)
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+
+    @testSendmsgDontWait.client_skip
+    def _testSendmsgDontWait(self):
+        try:
+            with self.assertRaises(socket.error) as cm:
+                while True:
+                    self.sendmsgToServer([b"a"*512], [], socket.MSG_DONTWAIT)
+            self.assertIn(cm.exception.errno,
+                          (errno.EAGAIN, errno.EWOULDBLOCK))
+        finally:
+            self.misc_event.set()
+
+
+class SendmsgConnectionlessTests(SendmsgTests):
+    # Tests for sendmsg() which require a connectionless-mode
+    # (e.g. datagram) socket, and do not involve recvmsg() or
+    # recvmsg_into().
+
+    def testSendmsgNoDestAddr(self):
+        # Check that sendmsg() fails when no destination address is
+        # given for unconnected socket.
+        pass
+
+    def _testSendmsgNoDestAddr(self):
+        self.assertRaises(socket.error, self.cli_sock.sendmsg,
+                          [MSG])
+        self.assertRaises(socket.error, self.cli_sock.sendmsg,
+                          [MSG], [], 0, None)
+
+
+class RecvmsgGenericTests(SendrecvmsgBase):
+    # Tests for recvmsg() which can also be emulated using
+    # recvmsg_into(), and can use any socket type.
+
+    def testRecvmsg(self):
+        # Receive a simple message with recvmsg[_into]().
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, len(MSG))
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsg(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgExplicitDefaults(self):
+        # Test recvmsg[_into]() with default arguments provided explicitly.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 0, 0)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgExplicitDefaults(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgShorter(self):
+        # Receive a message smaller than buffer.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG) + 42)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgShorter(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgTrunc(self):
+        # Receive part of message, check for truncation indicators.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG) - 3)
+        self.assertEqual(msg, MSG[:-3])
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=False)
+
+    def _testRecvmsgTrunc(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgShortAncillaryBuf(self):
+        # Test ancillary data buffer too small to hold any ancillary data.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 1)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgShortAncillaryBuf(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgLongAncillaryBuf(self):
+        # Test large ancillary data buffer.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 10240)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgLongAncillaryBuf(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgAfterClose(self):
+        # Check that recvmsg[_into]() fails on a closed socket.
+        self.serv_sock.close()
+        self.assertRaises(socket.error, self.doRecvmsg, self.serv_sock, 1024)
+
+    def _testRecvmsgAfterClose(self):
+        pass
+
+    def testRecvmsgTimeout(self):
+        # Check that timeout works.
+        try:
+            self.serv_sock.settimeout(0.03)
+            self.assertRaises(socket.timeout,
+                              self.doRecvmsg, self.serv_sock, len(MSG))
+        finally:
+            self.misc_event.set()
+
+    def _testRecvmsgTimeout(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+
+    @requireAttrs(socket, "MSG_PEEK")
+    def testRecvmsgPeek(self):
+        # Check that MSG_PEEK in flags enables examination of pending
+        # data without consuming it.
+
+        # Receive part of data with MSG_PEEK.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG) - 3, 0,
+                                                   socket.MSG_PEEK)
+        self.assertEqual(msg, MSG[:-3])
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        # Ignoring MSG_TRUNC here (so this test is the same for stream
+        # and datagram sockets).  Some wording in POSIX seems to
+        # suggest that it needn't be set when peeking, but that may
+        # just be a slip.
+        self.checkFlags(flags, eor=False,
+                        ignore=getattr(socket, "MSG_TRUNC", 0))
+
+        # Receive all data with MSG_PEEK.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 0,
+                                                   socket.MSG_PEEK)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+        # Check that the same data can still be received normally.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, len(MSG))
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    @testRecvmsgPeek.client_skip
+    def _testRecvmsgPeek(self):
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket.socket, "sendmsg")
+    def testRecvmsgFromSendmsg(self):
+        # Test receiving with recvmsg[_into]() when message is sent
+        # using sendmsg().
+        self.serv_sock.settimeout(self.fail_timeout)
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, len(MSG))
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    @testRecvmsgFromSendmsg.client_skip
+    def _testRecvmsgFromSendmsg(self):
+        self.assertEqual(self.sendmsgToServer([MSG[:3], MSG[3:]]), len(MSG))
+
+
+class RecvmsgGenericStreamTests(RecvmsgGenericTests):
+    # Tests which require a stream socket and can use either recvmsg()
+    # or recvmsg_into().
+
+    def testRecvmsgEOF(self):
+        # Receive end-of-stream indicator (b"", peer socket closed).
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, 1024)
+        self.assertEqual(msg, b"")
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=None) # Might not have end-of-record marker
+
+    def _testRecvmsgEOF(self):
+        self.cli_sock.close()
+
+    def testRecvmsgOverflow(self):
+        # Receive a message in more than one chunk.
+        seg1, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                    len(MSG) - 3)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=False)
+
+        seg2, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, 1024)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+        msg = seg1 + seg2
+        self.assertEqual(msg, MSG)
+
+    def _testRecvmsgOverflow(self):
+        self.sendToServer(MSG)
+
+
+class RecvmsgTests(RecvmsgGenericTests):
+    # Tests for recvmsg() which can use any socket type.
+
+    def testRecvmsgBadArgs(self):
+        # Check that recvmsg() rejects invalid arguments.
+        self.assertRaises(TypeError, self.serv_sock.recvmsg)
+        self.assertRaises(ValueError, self.serv_sock.recvmsg,
+                          -1, 0, 0)
+        self.assertRaises(ValueError, self.serv_sock.recvmsg,
+                          len(MSG), -1, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg,
+                          [bytearray(10)], 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg,
+                          object(), 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg,
+                          len(MSG), object(), 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg,
+                          len(MSG), 0, object())
+
+        msg, ancdata, flags, addr = self.serv_sock.recvmsg(len(MSG), 0, 0)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgBadArgs(self):
+        self.sendToServer(MSG)
+
+
+class RecvmsgIntoTests(RecvmsgIntoMixin, RecvmsgGenericTests):
+    # Tests for recvmsg_into() which can use any socket type.
+
+    def testRecvmsgIntoBadArgs(self):
+        # Check that recvmsg_into() rejects invalid arguments.
+        buf = bytearray(len(MSG))
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          len(MSG), 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          buf, 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [object()], 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [b"I'm not writable"], 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [buf, object()], 0, 0)
+        self.assertRaises(ValueError, self.serv_sock.recvmsg_into,
+                          [buf], -1, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [buf], object(), 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [buf], 0, object())
+
+        nbytes, ancdata, flags, addr = self.serv_sock.recvmsg_into([buf], 0, 0)
+        self.assertEqual(nbytes, len(MSG))
+        self.assertEqual(buf, bytearray(MSG))
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgIntoBadArgs(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgIntoGenerator(self):
+        # Receive into buffer obtained from a generator (not a sequence).
+        buf = bytearray(len(MSG))
+        nbytes, ancdata, flags, addr = self.serv_sock.recvmsg_into(
+            (o for o in [buf]))
+        self.assertEqual(nbytes, len(MSG))
+        self.assertEqual(buf, bytearray(MSG))
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgIntoGenerator(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgIntoArray(self):
+        # Receive into an array rather than the usual bytearray.
+        buf = array.array("B", [0] * len(MSG))
+        nbytes, ancdata, flags, addr = self.serv_sock.recvmsg_into([buf])
+        self.assertEqual(nbytes, len(MSG))
+        self.assertEqual(buf.tostring(), MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgIntoArray(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgIntoScatter(self):
+        # Receive into multiple buffers (scatter write).
+        b1 = bytearray(b"----")
+        b2 = bytearray(b"0123456789")
+        b3 = bytearray(b"--------------")
+        nbytes, ancdata, flags, addr = self.serv_sock.recvmsg_into(
+            [b1, memoryview(b2)[2:9], b3])
+        self.assertEqual(nbytes, len(b"Mary had a little lamb"))
+        self.assertEqual(b1, bytearray(b"Mary"))
+        self.assertEqual(b2, bytearray(b"01 had a 9"))
+        self.assertEqual(b3, bytearray(b"little lamb---"))
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgIntoScatter(self):
+        self.sendToServer(b"Mary had a little lamb")
+
+
+class CmsgMacroTests(unittest.TestCase):
+    # Test the functions CMSG_LEN() and CMSG_SPACE().  Tests
+    # assumptions used by sendmsg() and recvmsg[_into](), which share
+    # code with these functions.
+
+    # Match the definition in socketmodule.c
+    socklen_t_limit = min(0x7fffffff, _testcapi.INT_MAX)
+
+    @requireAttrs(socket, "CMSG_LEN")
+    def testCMSG_LEN(self):
+        # Test CMSG_LEN() with various valid and invalid values,
+        # checking the assumptions used by recvmsg() and sendmsg().
+        toobig = self.socklen_t_limit - socket.CMSG_LEN(0) + 1
+        values = list(range(257)) + list(range(toobig - 257, toobig))
+
+        # struct cmsghdr has at least three members, two of which are ints
+        self.assertGreater(socket.CMSG_LEN(0), array.array("i").itemsize * 2)
+        for n in values:
+            ret = socket.CMSG_LEN(n)
+            # This is how recvmsg() calculates the data size
+            self.assertEqual(ret - socket.CMSG_LEN(0), n)
+            self.assertLessEqual(ret, self.socklen_t_limit)
+
+        self.assertRaises(OverflowError, socket.CMSG_LEN, -1)
+        # sendmsg() shares code with these functions, and requires
+        # that it reject values over the limit.
+        self.assertRaises(OverflowError, socket.CMSG_LEN, toobig)
+        self.assertRaises(OverflowError, socket.CMSG_LEN, sys.maxsize)
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testCMSG_SPACE(self):
+        # Test CMSG_SPACE() with various valid and invalid values,
+        # checking the assumptions used by sendmsg().
+        toobig = self.socklen_t_limit - socket.CMSG_SPACE(1) + 1
+        values = list(range(257)) + list(range(toobig - 257, toobig))
+
+        last = socket.CMSG_SPACE(0)
+        # struct cmsghdr has at least three members, two of which are ints
+        self.assertGreater(last, array.array("i").itemsize * 2)
+        for n in values:
+            ret = socket.CMSG_SPACE(n)
+            self.assertGreaterEqual(ret, last)
+            self.assertGreaterEqual(ret, socket.CMSG_LEN(n))
+            self.assertGreaterEqual(ret, n + socket.CMSG_LEN(0))
+            self.assertLessEqual(ret, self.socklen_t_limit)
+            last = ret
+
+        self.assertRaises(OverflowError, socket.CMSG_SPACE, -1)
+        # sendmsg() shares code with these functions, and requires
+        # that it reject values over the limit.
+        self.assertRaises(OverflowError, socket.CMSG_SPACE, toobig)
+        self.assertRaises(OverflowError, socket.CMSG_SPACE, sys.maxsize)
+
+
+class SCMRightsTest(SendrecvmsgServerTimeoutBase):
+    # Tests for file descriptor passing on Unix-domain sockets.
+
+    # Invalid file descriptor value that's unlikely to evaluate to a
+    # real FD even if one of its bytes is replaced with a different
+    # value (which shouldn't actually happen).
+    badfd = -0x5555
+
+    def newFDs(self, n):
+        # Return a list of n file descriptors for newly-created files
+        # containing their list indices as ASCII numbers.
+        fds = []
+        for i in range(n):
+            fd, path = tempfile.mkstemp()
+            self.addCleanup(os.unlink, path)
+            self.addCleanup(os.close, fd)
+            os.write(fd, str(i).encode())
+            fds.append(fd)
+        return fds
+
+    def checkFDs(self, fds):
+        # Check that the file descriptors in the given list contain
+        # their correct list indices as ASCII numbers.
+        for n, fd in enumerate(fds):
+            os.lseek(fd, 0, os.SEEK_SET)
+            self.assertEqual(os.read(fd, 1024), str(n).encode())
+
+    def registerRecvmsgResult(self, result):
+        self.addCleanup(self.closeRecvmsgFDs, result)
+
+    def closeRecvmsgFDs(self, recvmsg_result):
+        # Close all file descriptors specified in the ancillary data
+        # of the given return value from recvmsg() or recvmsg_into().
+        for cmsg_level, cmsg_type, cmsg_data in recvmsg_result[1]:
+            if (cmsg_level == socket.SOL_SOCKET and
+                    cmsg_type == socket.SCM_RIGHTS):
+                fds = array.array("i")
+                fds.fromstring(cmsg_data[:
+                        len(cmsg_data) - (len(cmsg_data) % fds.itemsize)])
+                for fd in fds:
+                    os.close(fd)
+
+    def createAndSendFDs(self, n):
+        # Send n new file descriptors created by newFDs() to the
+        # server, with the constant MSG as the non-ancillary data.
+        self.assertEqual(
+            self.sendmsgToServer([MSG],
+                                 [(socket.SOL_SOCKET,
+                                   socket.SCM_RIGHTS,
+                                   array.array("i", self.newFDs(n)))]),
+            len(MSG))
+
+    def checkRecvmsgFDs(self, numfds, result, maxcmsgs=1, ignoreflags=0):
+        # Check that constant MSG was received with numfds file
+        # descriptors in a maximum of maxcmsgs control messages (which
+        # must contain only complete integers).  By default, check
+        # that MSG_CTRUNC is unset, but ignore any flags in
+        # ignoreflags.
+        msg, ancdata, flags, addr = result
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkunset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+        self.assertIsInstance(ancdata, list)
+        self.assertLessEqual(len(ancdata), maxcmsgs)
+        fds = array.array("i")
+        for item in ancdata:
+            self.assertIsInstance(item, tuple)
+            cmsg_level, cmsg_type, cmsg_data = item
+            self.assertEqual(cmsg_level, socket.SOL_SOCKET)
+            self.assertEqual(cmsg_type, socket.SCM_RIGHTS)
+            self.assertIsInstance(cmsg_data, bytes)
+            self.assertEqual(len(cmsg_data) % SIZEOF_INT, 0)
+            fds.fromstring(cmsg_data)
+
+        self.assertEqual(len(fds), numfds)
+        self.checkFDs(fds)
+
+    def testFDPassSimple(self):
+        # Pass a single FD (array read from bytes object).
+        self.checkRecvmsgFDs(1, self.doRecvmsg(self.serv_sock,
+                                               len(MSG), 10240))
+
+    def _testFDPassSimple(self):
+        self.assertEqual(
+            self.sendmsgToServer(
+                [MSG],
+                [(socket.SOL_SOCKET,
+                  socket.SCM_RIGHTS,
+                  array.array("i", self.newFDs(1)).tostring())]),
+            len(MSG))
+
+    def testMultipleFDPass(self):
+        # Pass multiple FDs in a single array.
+        self.checkRecvmsgFDs(4, self.doRecvmsg(self.serv_sock,
+                                               len(MSG), 10240))
+
+    def _testMultipleFDPass(self):
+        self.createAndSendFDs(4)
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testFDPassCMSG_SPACE(self):
+        # Test using CMSG_SPACE() to calculate ancillary buffer size.
+        self.checkRecvmsgFDs(
+            4, self.doRecvmsg(self.serv_sock, len(MSG),
+                              socket.CMSG_SPACE(4 * SIZEOF_INT)))
+
+    @testFDPassCMSG_SPACE.client_skip
+    def _testFDPassCMSG_SPACE(self):
+        self.createAndSendFDs(4)
+
+    def testFDPassCMSG_LEN(self):
+        # Test using CMSG_LEN() to calculate ancillary buffer size.
+        self.checkRecvmsgFDs(1,
+                             self.doRecvmsg(self.serv_sock, len(MSG),
+                                            socket.CMSG_LEN(4 * SIZEOF_INT)),
+                             # RFC 3542 says implementations may set
+                             # MSG_CTRUNC if there isn't enough space
+                             # for trailing padding.
+                             ignoreflags=socket.MSG_CTRUNC)
+
+    def _testFDPassCMSG_LEN(self):
+        self.createAndSendFDs(1)
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testFDPassSeparate(self):
+        # Pass two FDs in two separate arrays.  Arrays may be combined
+        # into a single control message by the OS.
+        self.checkRecvmsgFDs(2,
+                             self.doRecvmsg(self.serv_sock, len(MSG), 10240),
+                             maxcmsgs=2)
+
+    @testFDPassSeparate.client_skip
+    def _testFDPassSeparate(self):
+        fd0, fd1 = self.newFDs(2)
+        self.assertEqual(
+            self.sendmsgToServer([MSG], [(socket.SOL_SOCKET,
+                                          socket.SCM_RIGHTS,
+                                          array.array("i", [fd0])),
+                                         (socket.SOL_SOCKET,
+                                          socket.SCM_RIGHTS,
+                                          array.array("i", [fd1]))]),
+            len(MSG))
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testFDPassSeparateMinSpace(self):
+        # Pass two FDs in two separate arrays, receiving them into the
+        # minimum space for two arrays.
+        self.checkRecvmsgFDs(2,
+                             self.doRecvmsg(self.serv_sock, len(MSG),
+                                            socket.CMSG_SPACE(SIZEOF_INT) +
+                                            socket.CMSG_LEN(SIZEOF_INT)),
+                             maxcmsgs=2, ignoreflags=socket.MSG_CTRUNC)
+
+    @testFDPassSeparateMinSpace.client_skip
+    def _testFDPassSeparateMinSpace(self):
+        fd0, fd1 = self.newFDs(2)
+        self.assertEqual(
+            self.sendmsgToServer([MSG], [(socket.SOL_SOCKET,
+                                          socket.SCM_RIGHTS,
+                                          array.array("i", [fd0])),
+                                         (socket.SOL_SOCKET,
+                                          socket.SCM_RIGHTS,
+                                          array.array("i", [fd1]))]),
+            len(MSG))
+
+    def sendAncillaryIfPossible(self, msg, ancdata):
+        # Try to send msg and ancdata to server, but if the system
+        # call fails, just send msg with no ancillary data.
+        try:
+            nbytes = self.sendmsgToServer([msg], ancdata)
+        except socket.error as e:
+            # Check that it was the system call that failed
+            self.assertIsInstance(e.errno, int)
+            nbytes = self.sendmsgToServer([msg])
+        self.assertEqual(nbytes, len(msg))
+
+    def testFDPassEmpty(self):
+        # Try to pass an empty FD array.  Can receive either no array
+        # or an empty array.
+        self.checkRecvmsgFDs(0, self.doRecvmsg(self.serv_sock,
+                                               len(MSG), 10240),
+                             ignoreflags=socket.MSG_CTRUNC)
+
+    def _testFDPassEmpty(self):
+        self.sendAncillaryIfPossible(MSG, [(socket.SOL_SOCKET,
+                                            socket.SCM_RIGHTS,
+                                            b"")])
+
+    def testFDPassPartialInt(self):
+        # Try to pass a truncated FD array.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 10240)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, ignore=socket.MSG_CTRUNC)
+        self.assertLessEqual(len(ancdata), 1)
+        for cmsg_level, cmsg_type, cmsg_data in ancdata:
+            self.assertEqual(cmsg_level, socket.SOL_SOCKET)
+            self.assertEqual(cmsg_type, socket.SCM_RIGHTS)
+            self.assertLess(len(cmsg_data), SIZEOF_INT)
+
+    def _testFDPassPartialInt(self):
+        self.sendAncillaryIfPossible(
+            MSG,
+            [(socket.SOL_SOCKET,
+              socket.SCM_RIGHTS,
+              array.array("i", [self.badfd]).tostring()[:-1])])
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testFDPassPartialIntInMiddle(self):
+        # Try to pass two FD arrays, the first of which is truncated.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 10240)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, ignore=socket.MSG_CTRUNC)
+        self.assertLessEqual(len(ancdata), 2)
+        fds = array.array("i")
+        # Arrays may have been combined in a single control message
+        for cmsg_level, cmsg_type, cmsg_data in ancdata:
+            self.assertEqual(cmsg_level, socket.SOL_SOCKET)
+            self.assertEqual(cmsg_type, socket.SCM_RIGHTS)
+            fds.fromstring(cmsg_data[:
+                    len(cmsg_data) - (len(cmsg_data) % fds.itemsize)])
+        self.assertLessEqual(len(fds), 2)
+        self.checkFDs(fds)
+
+    @testFDPassPartialIntInMiddle.client_skip
+    def _testFDPassPartialIntInMiddle(self):
+        fd0, fd1 = self.newFDs(2)
+        self.sendAncillaryIfPossible(
+            MSG,
+            [(socket.SOL_SOCKET,
+              socket.SCM_RIGHTS,
+              array.array("i", [fd0, self.badfd]).tostring()[:-1]),
+             (socket.SOL_SOCKET,
+              socket.SCM_RIGHTS,
+              array.array("i", [fd1]))])
+
+    def checkTruncatedHeader(self, result, ignoreflags=0):
+        # Check that no ancillary data items are returned when data is
+        # truncated inside the cmsghdr structure.
+        msg, ancdata, flags, addr = result
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+    def testCmsgTruncNoBufSize(self):
+        # Check that no ancillary data is received when no buffer size
+        # is specified.
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG)),
+                                  # BSD seems to set MSG_CTRUNC only
+                                  # if an item has been partially
+                                  # received.
+                                  ignoreflags=socket.MSG_CTRUNC)
+
+    def _testCmsgTruncNoBufSize(self):
+        self.createAndSendFDs(1)
+
+    def testCmsgTrunc0(self):
+        # Check that no ancillary data is received when buffer size is 0.
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG), 0),
+                                  ignoreflags=socket.MSG_CTRUNC)
+
+    def _testCmsgTrunc0(self):
+        self.createAndSendFDs(1)
+
+    # Check that no ancillary data is returned for various non-zero
+    # (but still too small) buffer sizes.
+
+    def testCmsgTrunc1(self):
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG), 1))
+
+    def _testCmsgTrunc1(self):
+        self.createAndSendFDs(1)
+
+    def testCmsgTrunc2Int(self):
+        # The cmsghdr structure has at least three members, two of
+        # which are ints, so we still shouldn't see any ancillary
+        # data.
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG),
+                                                 SIZEOF_INT * 2))
+
+    def _testCmsgTrunc2Int(self):
+        self.createAndSendFDs(1)
+
+    def testCmsgTruncLen0Minus1(self):
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG),
+                                                 socket.CMSG_LEN(0) - 1))
+
+    def _testCmsgTruncLen0Minus1(self):
+        self.createAndSendFDs(1)
+
+    # The following tests try to truncate the control message in the
+    # middle of the FD array.
+
+    def checkTruncatedArray(self, ancbuf, maxdata, mindata=0):
+        # Check that file descriptor data is truncated to between
+        # mindata and maxdata bytes when received with buffer size
+        # ancbuf, and that any complete file descriptor numbers are
+        # valid.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), ancbuf)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC)
+
+        if mindata == 0 and ancdata == []:
+            return
+        self.assertEqual(len(ancdata), 1)
+        cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+        self.assertEqual(cmsg_level, socket.SOL_SOCKET)
+        self.assertEqual(cmsg_type, socket.SCM_RIGHTS)
+        self.assertGreaterEqual(len(cmsg_data), mindata)
+        self.assertLessEqual(len(cmsg_data), maxdata)
+        fds = array.array("i")
+        fds.fromstring(cmsg_data[:
+                len(cmsg_data) - (len(cmsg_data) % fds.itemsize)])
+        self.checkFDs(fds)
+
+    def testCmsgTruncLen0(self):
+        self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0), maxdata=0)
+
+    def _testCmsgTruncLen0(self):
+        self.createAndSendFDs(1)
+
+    def testCmsgTruncLen0Plus1(self):
+        self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0) + 1, maxdata=1)
+
+    def _testCmsgTruncLen0Plus1(self):
+        self.createAndSendFDs(2)
+
+    def testCmsgTruncLen1(self):
+        self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(SIZEOF_INT),
+                                 maxdata=SIZEOF_INT)
+
+    def _testCmsgTruncLen1(self):
+        self.createAndSendFDs(2)
+
+    def testCmsgTruncLen2Minus1(self):
+        self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(2 * SIZEOF_INT) - 1,
+                                 maxdata=(2 * SIZEOF_INT) - 1)
+
+    def _testCmsgTruncLen2Minus1(self):
+        self.createAndSendFDs(2)
+
+
+class RFC3542AncillaryTest(SendrecvmsgServerTimeoutBase):
+    # Test sendmsg() and recvmsg[_into]() using the ancillary data
+    # features of the RFC 3542 Advanced Sockets API for IPv6.
+    # Currently we can only handle certain data items (e.g. traffic
+    # class, hop limit, MTU discovery and fragmentation settings)
+    # without resorting to unportable means such as the struct module,
+    # but the tests here are aimed at testing the ancillary data
+    # handling in sendmsg() and recvmsg() rather than the IPv6 API
+    # itself.
+
+    # Test value to use when setting hop limit of packet
+    hop_limit = 2
+
+    # Test value to use when setting traffic class of packet.
+    # -1 means "use kernel default".
+    traffic_class = -1
+
+    def ancillaryMapping(self, ancdata):
+        # Given ancillary data list ancdata, return a mapping from
+        # pairs (cmsg_level, cmsg_type) to corresponding cmsg_data.
+        # Check that no (level, type) pair appears more than once.
+        d = {}
+        for cmsg_level, cmsg_type, cmsg_data in ancdata:
+            self.assertNotIn((cmsg_level, cmsg_type), d)
+            d[(cmsg_level, cmsg_type)] = cmsg_data
+        return d
+
+    def checkHopLimit(self, ancbufsize, maxhop=255, ignoreflags=0):
+        # Receive hop limit into ancbufsize bytes of ancillary data
+        # space.  Check that data is MSG, ancillary data is not
+        # truncated (but ignore any flags in ignoreflags), and hop
+        # limit is between 0 and maxhop inclusive.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), ancbufsize)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkunset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+        self.assertEqual(len(ancdata), 1)
+        self.assertIsInstance(ancdata[0], tuple)
+        cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+        self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+        self.assertEqual(cmsg_type, socket.IPV6_HOPLIMIT)
+        self.assertIsInstance(cmsg_data, bytes)
+        self.assertEqual(len(cmsg_data), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(cmsg_data)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], maxhop)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testRecvHopLimit(self):
+        # Test receiving the packet hop limit as ancillary data.
+        self.checkHopLimit(ancbufsize=10240)
+
+    @testRecvHopLimit.client_skip
+    def _testRecvHopLimit(self):
+        # Need to wait until server has asked to receive ancillary
+        # data, as implementations are not required to buffer it
+        # otherwise.
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testRecvHopLimitCMSG_SPACE(self):
+        # Test receiving hop limit, using CMSG_SPACE to calculate buffer size.
+        self.checkHopLimit(ancbufsize=socket.CMSG_SPACE(SIZEOF_INT))
+
+    @testRecvHopLimitCMSG_SPACE.client_skip
+    def _testRecvHopLimitCMSG_SPACE(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    # Could test receiving into buffer sized using CMSG_LEN, but RFC
+    # 3542 says portable applications must provide space for trailing
+    # padding.  Implementations may set MSG_CTRUNC if there isn't
+    # enough space for the padding.
+
+    @requireAttrs(socket.socket, "sendmsg")
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSetHopLimit(self):
+        # Test setting hop limit on outgoing packet and receiving it
+        # at the other end.
+        self.checkHopLimit(ancbufsize=10240, maxhop=self.hop_limit)
+
+    @testSetHopLimit.client_skip
+    def _testSetHopLimit(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.assertEqual(
+            self.sendmsgToServer([MSG],
+                                 [(socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT,
+                                   array.array("i", [self.hop_limit]))]),
+            len(MSG))
+
+    def checkTrafficClassAndHopLimit(self, ancbufsize, maxhop=255,
+                                     ignoreflags=0):
+        # Receive traffic class and hop limit into ancbufsize bytes of
+        # ancillary data space.  Check that data is MSG, ancillary
+        # data is not truncated (but ignore any flags in ignoreflags),
+        # and traffic class and hop limit are in range (hop limit no
+        # more than maxhop).
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVTCLASS, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), ancbufsize)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkunset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+        self.assertEqual(len(ancdata), 2)
+        ancmap = self.ancillaryMapping(ancdata)
+
+        tcdata = ancmap[(socket.IPPROTO_IPV6, socket.IPV6_TCLASS)]
+        self.assertEqual(len(tcdata), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(tcdata)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], 255)
+
+        hldata = ancmap[(socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT)]
+        self.assertEqual(len(hldata), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(hldata)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], maxhop)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testRecvTrafficClassAndHopLimit(self):
+        # Test receiving traffic class and hop limit as ancillary data.
+        self.checkTrafficClassAndHopLimit(ancbufsize=10240)
+
+    @testRecvTrafficClassAndHopLimit.client_skip
+    def _testRecvTrafficClassAndHopLimit(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testRecvTrafficClassAndHopLimitCMSG_SPACE(self):
+        # Test receiving traffic class and hop limit, using
+        # CMSG_SPACE() to calculate buffer size.
+        self.checkTrafficClassAndHopLimit(
+            ancbufsize=socket.CMSG_SPACE(SIZEOF_INT) * 2)
+
+    @testRecvTrafficClassAndHopLimitCMSG_SPACE.client_skip
+    def _testRecvTrafficClassAndHopLimitCMSG_SPACE(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket.socket, "sendmsg")
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSetTrafficClassAndHopLimit(self):
+        # Test setting traffic class and hop limit on outgoing packet,
+        # and receiving them at the other end.
+        self.checkTrafficClassAndHopLimit(ancbufsize=10240,
+                                          maxhop=self.hop_limit)
+
+    @testSetTrafficClassAndHopLimit.client_skip
+    def _testSetTrafficClassAndHopLimit(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.assertEqual(
+            self.sendmsgToServer([MSG],
+                                 [(socket.IPPROTO_IPV6, socket.IPV6_TCLASS,
+                                   array.array("i", [self.traffic_class])),
+                                  (socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT,
+                                   array.array("i", [self.hop_limit]))]),
+            len(MSG))
+
+    @requireAttrs(socket.socket, "sendmsg")
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testOddCmsgSize(self):
+        # Try to send ancillary data with first item one byte too
+        # long.  Fall back to sending with correct size if this fails,
+        # and check that second item was handled correctly.
+        self.checkTrafficClassAndHopLimit(ancbufsize=10240,
+                                          maxhop=self.hop_limit)
+
+    @testOddCmsgSize.client_skip
+    def _testOddCmsgSize(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        try:
+            nbytes = self.sendmsgToServer(
+                [MSG],
+                [(socket.IPPROTO_IPV6, socket.IPV6_TCLASS,
+                  array.array("i", [self.traffic_class]).tostring() + b"\x00"),
+                 (socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT,
+                  array.array("i", [self.hop_limit]))])
+        except socket.error as e:
+            self.assertIsInstance(e.errno, int)
+            nbytes = self.sendmsgToServer(
+                [MSG],
+                [(socket.IPPROTO_IPV6, socket.IPV6_TCLASS,
+                  array.array("i", [self.traffic_class])),
+                 (socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT,
+                  array.array("i", [self.hop_limit]))])
+            self.assertEqual(nbytes, len(MSG))
+
+    # Tests for proper handling of truncated ancillary data
+
+    def checkHopLimitTruncatedHeader(self, ancbufsize, ignoreflags=0):
+        # Receive hop limit into ancbufsize bytes of ancillary data
+        # space, which should be too small to contain the ancillary
+        # data header (if ancbufsize is None, pass no second argument
+        # to recvmsg()).  Check that data is MSG, MSG_CTRUNC is set
+        # (unless included in ignoreflags), and no ancillary data is
+        # returned.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.misc_event.set()
+        args = () if ancbufsize is None else (ancbufsize,)
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), *args)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testCmsgTruncNoBufSize(self):
+        # Check that no ancillary data is received when no ancillary
+        # buffer size is provided.
+        self.checkHopLimitTruncatedHeader(ancbufsize=None,
+                                          # BSD seems to set
+                                          # MSG_CTRUNC only if an item
+                                          # has been partially
+                                          # received.
+                                          ignoreflags=socket.MSG_CTRUNC)
+
+    @testCmsgTruncNoBufSize.client_skip
+    def _testCmsgTruncNoBufSize(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTrunc0(self):
+        # Check that no ancillary data is received when ancillary
+        # buffer size is zero.
+        self.checkHopLimitTruncatedHeader(ancbufsize=0,
+                                          ignoreflags=socket.MSG_CTRUNC)
+
+    @testSingleCmsgTrunc0.client_skip
+    def _testSingleCmsgTrunc0(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    # Check that no ancillary data is returned for various non-zero
+    # (but still too small) buffer sizes.
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTrunc1(self):
+        self.checkHopLimitTruncatedHeader(ancbufsize=1)
+
+    @testSingleCmsgTrunc1.client_skip
+    def _testSingleCmsgTrunc1(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTrunc2Int(self):
+        self.checkHopLimitTruncatedHeader(ancbufsize=2 * SIZEOF_INT)
+
+    @testSingleCmsgTrunc2Int.client_skip
+    def _testSingleCmsgTrunc2Int(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTruncLen0Minus1(self):
+        self.checkHopLimitTruncatedHeader(ancbufsize=socket.CMSG_LEN(0) - 1)
+
+    @testSingleCmsgTruncLen0Minus1.client_skip
+    def _testSingleCmsgTruncLen0Minus1(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTruncInData(self):
+        # Test truncation of a control message inside its associated
+        # data.  The message may be returned with its data truncated,
+        # or not returned at all.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(
+            self.serv_sock, len(MSG), socket.CMSG_LEN(SIZEOF_INT) - 1)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC)
+
+        self.assertLessEqual(len(ancdata), 1)
+        if ancdata:
+            cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+            self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+            self.assertEqual(cmsg_type, socket.IPV6_HOPLIMIT)
+            self.assertLess(len(cmsg_data), SIZEOF_INT)
+
+    @testSingleCmsgTruncInData.client_skip
+    def _testSingleCmsgTruncInData(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    def checkTruncatedSecondHeader(self, ancbufsize, ignoreflags=0):
+        # Receive traffic class and hop limit into ancbufsize bytes of
+        # ancillary data space, which should be large enough to
+        # contain the first item, but too small to contain the header
+        # of the second.  Check that data is MSG, MSG_CTRUNC is set
+        # (unless included in ignoreflags), and only one ancillary
+        # data item is returned.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVTCLASS, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), ancbufsize)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+        self.assertEqual(len(ancdata), 1)
+        cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+        self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+        self.assertIn(cmsg_type, {socket.IPV6_TCLASS, socket.IPV6_HOPLIMIT})
+        self.assertEqual(len(cmsg_data), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(cmsg_data)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], 255)
+
+    # Try the above test with various buffer sizes.
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecondCmsgTrunc0(self):
+        self.checkTruncatedSecondHeader(socket.CMSG_SPACE(SIZEOF_INT),
+                                        ignoreflags=socket.MSG_CTRUNC)
+
+    @testSecondCmsgTrunc0.client_skip
+    def _testSecondCmsgTrunc0(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecondCmsgTrunc1(self):
+        self.checkTruncatedSecondHeader(socket.CMSG_SPACE(SIZEOF_INT) + 1)
+
+    @testSecondCmsgTrunc1.client_skip
+    def _testSecondCmsgTrunc1(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecondCmsgTrunc2Int(self):
+        self.checkTruncatedSecondHeader(socket.CMSG_SPACE(SIZEOF_INT) +
+                                        2 * SIZEOF_INT)
+
+    @testSecondCmsgTrunc2Int.client_skip
+    def _testSecondCmsgTrunc2Int(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecondCmsgTruncLen0Minus1(self):
+        self.checkTruncatedSecondHeader(socket.CMSG_SPACE(SIZEOF_INT) +
+                                        socket.CMSG_LEN(0) - 1)
+
+    @testSecondCmsgTruncLen0Minus1.client_skip
+    def _testSecondCmsgTruncLen0Minus1(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecomdCmsgTruncInData(self):
+        # Test truncation of the second of two control messages inside
+        # its associated data.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVTCLASS, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(
+            self.serv_sock, len(MSG),
+            socket.CMSG_SPACE(SIZEOF_INT) + socket.CMSG_LEN(SIZEOF_INT) - 1)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC)
+
+        cmsg_types = {socket.IPV6_TCLASS, socket.IPV6_HOPLIMIT}
+
+        cmsg_level, cmsg_type, cmsg_data = ancdata.pop(0)
+        self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+        cmsg_types.remove(cmsg_type)
+        self.assertEqual(len(cmsg_data), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(cmsg_data)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], 255)
+
+        if ancdata:
+            cmsg_level, cmsg_type, cmsg_data = ancdata.pop(0)
+            self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+            cmsg_types.remove(cmsg_type)
+            self.assertLess(len(cmsg_data), SIZEOF_INT)
+
+        self.assertEqual(ancdata, [])
+
+    @testSecomdCmsgTruncInData.client_skip
+    def _testSecomdCmsgTruncInData(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+
+# Derive concrete test classes for different socket types.
+
+class SendrecvmsgUDPTestBase(SendrecvmsgDgramFlagsBase,
+                             SendrecvmsgConnectionlessBase,
+                             ThreadedSocketTestMixin, UDPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgUDPTest(SendmsgConnectionlessTests, SendrecvmsgUDPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgUDPTest(RecvmsgTests, SendrecvmsgUDPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoUDPTest(RecvmsgIntoTests, SendrecvmsgUDPTestBase):
+    pass
+
+
+class SendrecvmsgUDP6TestBase(SendrecvmsgDgramFlagsBase,
+                              SendrecvmsgConnectionlessBase,
+                              ThreadedSocketTestMixin, UDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgUDP6Test(SendmsgConnectionlessTests, SendrecvmsgUDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgUDP6Test(RecvmsgTests, SendrecvmsgUDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoUDP6Test(RecvmsgIntoTests, SendrecvmsgUDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireAttrs(socket, "IPPROTO_IPV6")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgRFC3542AncillaryUDP6Test(RFC3542AncillaryTest,
+                                      SendrecvmsgUDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireAttrs(socket, "IPPROTO_IPV6")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoRFC3542AncillaryUDP6Test(RecvmsgIntoMixin,
+                                          RFC3542AncillaryTest,
+                                          SendrecvmsgUDP6TestBase):
+    pass
+
+
+class SendrecvmsgTCPTestBase(SendrecvmsgConnectedBase,
+                             ConnectedStreamTestMixin, TCPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgTCPTest(SendmsgStreamTests, SendrecvmsgTCPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgTCPTest(RecvmsgTests, RecvmsgGenericStreamTests,
+                     SendrecvmsgTCPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoTCPTest(RecvmsgIntoTests, RecvmsgGenericStreamTests,
+                         SendrecvmsgTCPTestBase):
+    pass
+
+
+class SendrecvmsgSCTPStreamTestBase(SendrecvmsgSCTPFlagsBase,
+                                    SendrecvmsgConnectedBase,
+                                    ConnectedStreamTestMixin, SCTPStreamBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at requireSocket("AF_INET", "SOCK_STREAM", "IPPROTO_SCTP")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgSCTPStreamTest(SendmsgStreamTests, SendrecvmsgSCTPStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at requireSocket("AF_INET", "SOCK_STREAM", "IPPROTO_SCTP")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgSCTPStreamTest(RecvmsgTests, RecvmsgGenericStreamTests,
+                            SendrecvmsgSCTPStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at requireSocket("AF_INET", "SOCK_STREAM", "IPPROTO_SCTP")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoSCTPStreamTest(RecvmsgIntoTests, RecvmsgGenericStreamTests,
+                                SendrecvmsgSCTPStreamTestBase):
+    pass
+
+
+class SendrecvmsgUnixStreamTestBase(SendrecvmsgConnectedBase,
+                                    ConnectedStreamTestMixin, UnixStreamBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at requireAttrs(socket, "AF_UNIX")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgUnixStreamTest(SendmsgStreamTests, SendrecvmsgUnixStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at requireAttrs(socket, "AF_UNIX")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgUnixStreamTest(RecvmsgTests, RecvmsgGenericStreamTests,
+                            SendrecvmsgUnixStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at requireAttrs(socket, "AF_UNIX")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoUnixStreamTest(RecvmsgIntoTests, RecvmsgGenericStreamTests,
+                                SendrecvmsgUnixStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg", "recvmsg")
+ at requireAttrs(socket, "AF_UNIX", "SOL_SOCKET", "SCM_RIGHTS")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgSCMRightsStreamTest(SCMRightsTest, SendrecvmsgUnixStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg", "recvmsg_into")
+ at requireAttrs(socket, "AF_UNIX", "SOL_SOCKET", "SCM_RIGHTS")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoSCMRightsStreamTest(RecvmsgIntoMixin, SCMRightsTest,
+                                     SendrecvmsgUnixStreamTestBase):
+    pass
+
+
+# Test interrupting the interruptible send/receive methods with a
+# signal when a timeout is set.  These tests avoid having multiple
+# threads alive during the test so that the OS cannot deliver the
+# signal to the wrong one.
+
+class InterruptedTimeoutBase(unittest.TestCase):
+    # Base class for interrupted send/receive tests.  Installs an
+    # empty handler for SIGALRM and removes it on teardown, along with
+    # any scheduled alarms.
+
+    def setUp(self):
+        super().setUp()
+        orig_alrm_handler = signal.signal(signal.SIGALRM,
+                                          lambda signum, frame: None)
+        self.addCleanup(signal.signal, signal.SIGALRM, orig_alrm_handler)
+        self.addCleanup(self.setAlarm, 0)
+
+    # Timeout for socket operations
+    timeout = 4.0
+
+    # Provide setAlarm() method to schedule delivery of SIGALRM after
+    # given number of seconds, or cancel it if zero, and an
+    # appropriate time value to use.  Use setitimer() if available.
+    if hasattr(signal, "setitimer"):
+        alarm_time = 0.05
+
+        def setAlarm(self, seconds):
+            signal.setitimer(signal.ITIMER_REAL, seconds)
+    else:
+        # Old systems may deliver the alarm up to one second early
+        alarm_time = 2
+
+        def setAlarm(self, seconds):
+            signal.alarm(seconds)
+
+
+# Require siginterrupt() in order to ensure that system calls are
+# interrupted by default.
+ at requireAttrs(signal, "siginterrupt")
+ at unittest.skipUnless(hasattr(signal, "alarm") or hasattr(signal, "setitimer"),
+                     "Don't have signal.alarm or signal.setitimer")
+class InterruptedRecvTimeoutTest(InterruptedTimeoutBase, UDPTestBase):
+    # Test interrupting the recv*() methods with signals when a
+    # timeout is set.
+
+    def setUp(self):
+        super().setUp()
+        self.serv.settimeout(self.timeout)
+
+    def checkInterruptedRecv(self, func, *args, **kwargs):
+        # Check that func(*args, **kwargs) raises socket.error with an
+        # errno of EINTR when interrupted by a signal.
+        self.setAlarm(self.alarm_time)
+        with self.assertRaises(socket.error) as cm:
+            func(*args, **kwargs)
+        self.assertNotIsInstance(cm.exception, socket.timeout)
+        self.assertEqual(cm.exception.errno, errno.EINTR)
+
+    def testInterruptedRecvTimeout(self):
+        self.checkInterruptedRecv(self.serv.recv, 1024)
+
+    def testInterruptedRecvIntoTimeout(self):
+        self.checkInterruptedRecv(self.serv.recv_into, bytearray(1024))
+
+    def testInterruptedRecvfromTimeout(self):
+        self.checkInterruptedRecv(self.serv.recvfrom, 1024)
+
+    def testInterruptedRecvfromIntoTimeout(self):
+        self.checkInterruptedRecv(self.serv.recvfrom_into, bytearray(1024))
+
+    @requireAttrs(socket.socket, "recvmsg")
+    def testInterruptedRecvmsgTimeout(self):
+        self.checkInterruptedRecv(self.serv.recvmsg, 1024)
+
+    @requireAttrs(socket.socket, "recvmsg_into")
+    def testInterruptedRecvmsgIntoTimeout(self):
+        self.checkInterruptedRecv(self.serv.recvmsg_into, [bytearray(1024)])
+
+
+# Require siginterrupt() in order to ensure that system calls are
+# interrupted by default.
+ at requireAttrs(signal, "siginterrupt")
+ at unittest.skipUnless(hasattr(signal, "alarm") or hasattr(signal, "setitimer"),
+                     "Don't have signal.alarm or signal.setitimer")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class InterruptedSendTimeoutTest(InterruptedTimeoutBase,
+                                 ThreadSafeCleanupTestCase,
+                                 SocketListeningTestMixin, TCPTestBase):
+    # Test interrupting the interruptible send*() methods with signals
+    # when a timeout is set.
+
+    def setUp(self):
+        super().setUp()
+        self.serv_conn = self.newSocket()
+        self.addCleanup(self.serv_conn.close)
+        # Use a thread to complete the connection, but wait for it to
+        # terminate before running the test, so that there is only one
+        # thread to accept the signal.
+        cli_thread = threading.Thread(target=self.doConnect)
+        cli_thread.start()
+        self.cli_conn, addr = self.serv.accept()
+        self.addCleanup(self.cli_conn.close)
+        cli_thread.join()
+        self.serv_conn.settimeout(self.timeout)
+
+    def doConnect(self):
+        self.serv_conn.connect(self.serv_addr)
+
+    def checkInterruptedSend(self, func, *args, **kwargs):
+        # Check that func(*args, **kwargs), run in a loop, raises
+        # socket.error with an errno of EINTR when interrupted by a
+        # signal.
+        with self.assertRaises(socket.error) as cm:
+            while True:
+                self.setAlarm(self.alarm_time)
+                func(*args, **kwargs)
+        self.assertNotIsInstance(cm.exception, socket.timeout)
+        self.assertEqual(cm.exception.errno, errno.EINTR)
+
+    def testInterruptedSendTimeout(self):
+        self.checkInterruptedSend(self.serv_conn.send, b"a"*512)
+
+    def testInterruptedSendtoTimeout(self):
+        # Passing an actual address here as Python's wrapper for
+        # sendto() doesn't allow passing a zero-length one; POSIX
+        # requires that the address is ignored since the socket is
+        # connection-mode, however.
+        self.checkInterruptedSend(self.serv_conn.sendto, b"a"*512,
+                                  self.serv_addr)
+
+    @requireAttrs(socket.socket, "sendmsg")
+    def testInterruptedSendmsgTimeout(self):
+        self.checkInterruptedSend(self.serv_conn.sendmsg, [b"a"*512])
+
+
 @unittest.skipUnless(thread, 'Threading required for this test.')
 class TCPCloserTest(ThreadedTCPSocketTest):
 
@@ -2079,6 +4174,31 @@ def test_main():
     if isTipcAvailable():
         tests.append(TIPCTest)
         tests.append(TIPCThreadableTest)
+    tests.extend([
+        CmsgMacroTests,
+        SendmsgUDPTest,
+        RecvmsgUDPTest,
+        RecvmsgIntoUDPTest,
+        SendmsgUDP6Test,
+        RecvmsgUDP6Test,
+        RecvmsgRFC3542AncillaryUDP6Test,
+        RecvmsgIntoRFC3542AncillaryUDP6Test,
+        RecvmsgIntoUDP6Test,
+        SendmsgTCPTest,
+        RecvmsgTCPTest,
+        RecvmsgIntoTCPTest,
+        SendmsgSCTPStreamTest,
+        RecvmsgSCTPStreamTest,
+        RecvmsgIntoSCTPStreamTest,
+        SendmsgUnixStreamTest,
+        RecvmsgUnixStreamTest,
+        RecvmsgIntoUnixStreamTest,
+        RecvmsgSCMRightsStreamTest,
+        RecvmsgIntoSCMRightsStreamTest,
+        # These are slow when setitimer() is not available
+        InterruptedRecvTimeoutTest,
+        InterruptedSendTimeoutTest,
+    ])
 
     thread_info = support.threading_setup()
     support.run_unittest(*tests)
diff --git a/Lib/test/test_ssl.py b/Lib/test/test_ssl.py
--- a/Lib/test/test_ssl.py
+++ b/Lib/test/test_ssl.py
@@ -186,8 +186,11 @@ class BasicSocketTests(unittest.TestCase
         self.assertRaises(socket.error, ss.recv_into, bytearray(b'x'))
         self.assertRaises(socket.error, ss.recvfrom, 1)
         self.assertRaises(socket.error, ss.recvfrom_into, bytearray(b'x'), 1)
+        self.assertRaises(socket.error, ss.recvmsg, 1)
+        self.assertRaises(socket.error, ss.recvmsg_into, [bytearray(b'x')])
         self.assertRaises(socket.error, ss.send, b'x')
         self.assertRaises(socket.error, ss.sendto, b'x', ('0.0.0.0', 0))
+        self.assertRaises(socket.error, ss.sendmsg, [b'x'])
 
     def test_timeout(self):
         # Issue #8524: when creating an SSL socket, the timeout of the
@@ -1496,17 +1499,30 @@ else:
                     count, addr = s.recvfrom_into(b)
                     return b[:count]
 
+                def _recvmsg(*args, **kwargs):
+                    return s.recvmsg(*args, **kwargs)[0]
+
+                def _recvmsg_into(bufsize, *args, **kwargs):
+                    b = bytearray(bufsize)
+                    return bytes(b[:s.recvmsg_into([b], *args, **kwargs)[0]])
+
+                def _sendmsg(msg, *args, **kwargs):
+                    return s.sendmsg([msg])
+
                 # (name, method, whether to expect success, *args)
                 send_methods = [
                     ('send', s.send, True, []),
                     ('sendto', s.sendto, False, ["some.address"]),
+                    ('sendmsg', _sendmsg, False, []),
                     ('sendall', s.sendall, True, []),
                 ]
                 recv_methods = [
                     ('recv', s.recv, True, []),
                     ('recvfrom', s.recvfrom, False, ["some.address"]),
+                    ('recvmsg', _recvmsg, False, [100]),
                     ('recv_into', _recv_into, True, []),
                     ('recvfrom_into', _recvfrom_into, False, []),
+                    ('recvmsg_into', _recvmsg_into, False, [100]),
                 ]
                 data_prefix = "PREFIX_"
 
diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -263,6 +263,7 @@ if_indextoname(index) -- return the corr
 #ifdef HAVE_NET_IF_H
 #include <net/if.h>
 #endif
+#include <unistd.h>
 
 /* Generic socket object definitions and includes */
 #define PySocket_BUILDING_SOCKET
@@ -469,6 +470,17 @@ static PyTypeObject sock_type;
 #include <sys/poll.h>
 #endif
 
+/* Largest value to try to store in a socklen_t (used when handling
+   ancillary data).  POSIX requires socklen_t to hold at least
+   (2**31)-1 and recommends against storing larger values, but
+   socklen_t was originally int in the BSD interface, so to be on the
+   safe side we use the smaller of (2**31)-1 and INT_MAX. */
+#if INT_MAX > 0x7fffffff
+#define SOCKLEN_T_LIMIT 0x7fffffff
+#else
+#define SOCKLEN_T_LIMIT INT_MAX
+#endif
+
 #ifdef Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE
 /* Platform can select file descriptors beyond FD_SETSIZE */
 #define IS_SELECTABLE(s) 1
@@ -1678,6 +1690,117 @@ getsockaddrlen(PySocketSockObject *s, so
 }
 
 
+/* Support functions for the sendmsg() and recvmsg[_into]() methods.
+   Currently, these methods are only compiled if the RFC 2292/3542
+   CMSG_LEN() macro is available.  Older systems seem to have used
+   sizeof(struct cmsghdr) + (length) where CMSG_LEN() is used now, so
+   it may be possible to define CMSG_LEN() that way if it's not
+   provided.  Some architectures might need extra padding after the
+   cmsghdr, however, and CMSG_LEN() would have to take account of
+   this. */
+#ifdef CMSG_LEN
+/* If length is in range, set *result to CMSG_LEN(length) and return
+   true; otherwise, return false. */
+static int
+get_CMSG_LEN(size_t length, size_t *result)
+{
+    size_t tmp;
+
+    if (length > (SOCKLEN_T_LIMIT - CMSG_LEN(0)))
+        return 0;
+    tmp = CMSG_LEN(length);
+    if (tmp > SOCKLEN_T_LIMIT || tmp < length)
+        return 0;
+    *result = tmp;
+    return 1;
+}
+
+#ifdef CMSG_SPACE
+/* If length is in range, set *result to CMSG_SPACE(length) and return
+   true; otherwise, return false. */
+static int
+get_CMSG_SPACE(size_t length, size_t *result)
+{
+    size_t tmp;
+
+    /* Use CMSG_SPACE(1) here in order to take account of the padding
+       necessary before *and* after the data. */
+    if (length > (SOCKLEN_T_LIMIT - CMSG_SPACE(1)))
+        return 0;
+    tmp = CMSG_SPACE(length);
+    if (tmp > SOCKLEN_T_LIMIT || tmp < length)
+        return 0;
+    *result = tmp;
+    return 1;
+}
+#endif
+
+/* Return true iff msg->msg_controllen is valid, cmsgh is a valid
+   pointer in msg->msg_control with at least "space" bytes after it,
+   and its cmsg_len member inside the buffer. */
+static int
+cmsg_min_space(struct msghdr *msg, struct cmsghdr *cmsgh, size_t space)
+{
+    size_t cmsg_offset;
+    static const size_t cmsg_len_end = (offsetof(struct cmsghdr, cmsg_len) +
+                                        sizeof(cmsgh->cmsg_len));
+
+    if (cmsgh == NULL || msg->msg_control == NULL || msg->msg_controllen < 0)
+        return 0;
+    if (space < cmsg_len_end)
+        space = cmsg_len_end;
+    cmsg_offset = (char *)cmsgh - (char *)msg->msg_control;
+    return (cmsg_offset <= (size_t)-1 - space &&
+            cmsg_offset + space <= msg->msg_controllen);
+}
+
+/* If pointer CMSG_DATA(cmsgh) is in buffer msg->msg_control, set
+   *space to number of bytes following it in the buffer and return
+   true; otherwise, return false.  Assumes cmsgh, msg->msg_control and
+   msg->msg_controllen are valid. */
+static int
+get_cmsg_data_space(struct msghdr *msg, struct cmsghdr *cmsgh, size_t *space)
+{
+    size_t data_offset;
+    char *data_ptr;
+
+    if ((data_ptr = (char *)CMSG_DATA(cmsgh)) == NULL)
+        return 0;
+    data_offset = data_ptr - (char *)msg->msg_control;
+    if (data_offset > msg->msg_controllen)
+        return 0;
+    *space = msg->msg_controllen - data_offset;
+    return 1;
+}
+
+/* If cmsgh is invalid or not contained in the buffer pointed to by
+   msg->msg_control, return -1.  If cmsgh is valid and its associated
+   data is entirely contained in the buffer, set *data_len to the
+   length of the associated data and return 0.  If only part of the
+   associated data is contained in the buffer but cmsgh is otherwise
+   valid, set *data_len to the length contained in the buffer and
+   return 1. */
+static int
+get_cmsg_data_len(struct msghdr *msg, struct cmsghdr *cmsgh, size_t *data_len)
+{
+    size_t space, cmsg_data_len;
+
+    if (!cmsg_min_space(msg, cmsgh, CMSG_LEN(0)) ||
+        cmsgh->cmsg_len < CMSG_LEN(0))
+        return -1;
+    cmsg_data_len = cmsgh->cmsg_len - CMSG_LEN(0);
+    if (!get_cmsg_data_space(msg, cmsgh, &space))
+        return -1;
+    if (space >= cmsg_data_len) {
+        *data_len = cmsg_data_len;
+        return 0;
+    }
+    *data_len = space;
+    return 1;
+}
+#endif    /* CMSG_LEN */
+
+
 /* s._accept() -> (fd, address) */
 
 static PyObject *
@@ -2631,6 +2754,333 @@ PyDoc_STRVAR(recvfrom_into_doc,
 Like recv_into(buffer[, nbytes[, flags]]) but also return the sender's address info.");
 
 
+/* The sendmsg() and recvmsg[_into]() methods require a working
+   CMSG_LEN().  See the comment near get_CMSG_LEN(). */
+#ifdef CMSG_LEN
+/*
+ * Call recvmsg() with the supplied iovec structures, flags, and
+ * ancillary data buffer size (controllen).  Returns the tuple return
+ * value for recvmsg() or recvmsg_into(), with the first item provided
+ * by the supplied makeval() function.  makeval() will be called with
+ * the length read and makeval_data as arguments, and must return a
+ * new reference (which will be decrefed if there is a subsequent
+ * error).  On error, closes any file descriptors received via
+ * SCM_RIGHTS.
+ */
+static PyObject *
+sock_recvmsg_guts(PySocketSockObject *s, struct iovec *iov, int iovlen,
+                  int flags, Py_ssize_t controllen,
+                  PyObject *(*makeval)(ssize_t, void *), void *makeval_data)
+{
+    ssize_t bytes_received = -1;
+    int timeout;
+    sock_addr_t addrbuf;
+    socklen_t addrbuflen;
+    static const struct msghdr msg_blank;
+    struct msghdr msg;
+    PyObject *cmsg_list = NULL, *retval = NULL;
+    void *controlbuf = NULL;
+    struct cmsghdr *cmsgh;
+    size_t cmsgdatalen = 0;
+    int cmsg_status;
+
+    /* XXX: POSIX says that msg_name and msg_namelen "shall be
+       ignored" when the socket is connected (Linux fills them in
+       anyway for AF_UNIX sockets at least).  Normally msg_namelen
+       seems to be set to 0 if there's no address, but try to
+       initialize msg_name to something that won't be mistaken for a
+       real address if that doesn't happen. */
+    if (!getsockaddrlen(s, &addrbuflen))
+        return NULL;
+    memset(&addrbuf, 0, addrbuflen);
+    SAS2SA(&addrbuf)->sa_family = AF_UNSPEC;
+
+    if (controllen < 0 || controllen > SOCKLEN_T_LIMIT) {
+        PyErr_SetString(PyExc_ValueError,
+                        "invalid ancillary data buffer length");
+        return NULL;
+    }
+    if (controllen > 0 && (controlbuf = PyMem_Malloc(controllen)) == NULL)
+        return PyErr_NoMemory();
+
+    /* Make the system call. */
+    if (!IS_SELECTABLE(s)) {
+        select_error();
+        goto finally;
+    }
+
+    BEGIN_SELECT_LOOP(s)
+    Py_BEGIN_ALLOW_THREADS;
+    msg = msg_blank;    /* Set all members to 0 or NULL */
+    msg.msg_name = SAS2SA(&addrbuf);
+    msg.msg_namelen = addrbuflen;
+    msg.msg_iov = iov;
+    msg.msg_iovlen = iovlen;
+    msg.msg_control = controlbuf;
+    msg.msg_controllen = controllen;
+    timeout = internal_select_ex(s, 0, interval);
+    if (!timeout)
+        bytes_received = recvmsg(s->sock_fd, &msg, flags);
+    Py_END_ALLOW_THREADS;
+    if (timeout == 1) {
+        PyErr_SetString(socket_timeout, "timed out");
+        goto finally;
+    }
+    END_SELECT_LOOP(s)
+
+    if (bytes_received < 0) {
+        s->errorhandler();
+        goto finally;
+    }
+
+    /* Make list of (level, type, data) tuples from control messages. */
+    if ((cmsg_list = PyList_New(0)) == NULL)
+        goto err_closefds;
+    /* Check for empty ancillary data as old CMSG_FIRSTHDR()
+       implementations didn't do so. */
+    for (cmsgh = ((msg.msg_controllen > 0) ? CMSG_FIRSTHDR(&msg) : NULL);
+         cmsgh != NULL; cmsgh = CMSG_NXTHDR(&msg, cmsgh)) {
+        PyObject *bytes, *tuple;
+        int tmp;
+
+        cmsg_status = get_cmsg_data_len(&msg, cmsgh, &cmsgdatalen);
+        if (cmsg_status != 0) {
+            if (PyErr_WarnEx(PyExc_RuntimeWarning,
+                             "received malformed or improperly-truncated "
+                             "ancillary data", 1) == -1)
+                goto err_closefds;
+        }
+        if (cmsg_status < 0)
+            break;
+        if (cmsgdatalen > PY_SSIZE_T_MAX) {
+            PyErr_SetString(socket_error, "control message too long");
+            goto err_closefds;
+        }
+
+        bytes = PyBytes_FromStringAndSize((char *)CMSG_DATA(cmsgh),
+                                          cmsgdatalen);
+        tuple = Py_BuildValue("iiN", (int)cmsgh->cmsg_level,
+                              (int)cmsgh->cmsg_type, bytes);
+        if (tuple == NULL)
+            goto err_closefds;
+        tmp = PyList_Append(cmsg_list, tuple);
+        Py_DECREF(tuple);
+        if (tmp != 0)
+            goto err_closefds;
+
+        if (cmsg_status != 0)
+            break;
+    }
+
+    retval = Py_BuildValue("NOiN",
+                           (*makeval)(bytes_received, makeval_data),
+                           cmsg_list,
+                           (int)msg.msg_flags,
+                           makesockaddr(s->sock_fd, SAS2SA(&addrbuf),
+                                        ((msg.msg_namelen > addrbuflen) ?
+                                         addrbuflen : msg.msg_namelen),
+                                        s->sock_proto));
+    if (retval == NULL)
+        goto err_closefds;
+
+finally:
+    Py_XDECREF(cmsg_list);
+    PyMem_Free(controlbuf);
+    return retval;
+
+err_closefds:
+#ifdef SCM_RIGHTS
+    /* Close all descriptors coming from SCM_RIGHTS, so they don't leak. */
+    for (cmsgh = ((msg.msg_controllen > 0) ? CMSG_FIRSTHDR(&msg) : NULL);
+         cmsgh != NULL; cmsgh = CMSG_NXTHDR(&msg, cmsgh)) {
+        cmsg_status = get_cmsg_data_len(&msg, cmsgh, &cmsgdatalen);
+        if (cmsg_status < 0)
+            break;
+        if (cmsgh->cmsg_level == SOL_SOCKET &&
+            cmsgh->cmsg_type == SCM_RIGHTS) {
+            size_t numfds;
+            int *fdp;
+
+            numfds = cmsgdatalen / sizeof(int);
+            fdp = (int *)CMSG_DATA(cmsgh);
+            while (numfds-- > 0)
+                close(*fdp++);
+        }
+        if (cmsg_status != 0)
+            break;
+    }
+#endif /* SCM_RIGHTS */
+    goto finally;
+}
+
+
+static PyObject *
+makeval_recvmsg(ssize_t received, void *data)
+{
+    PyObject **buf = data;
+
+    if (received < PyBytes_GET_SIZE(*buf))
+        _PyBytes_Resize(buf, received);
+    Py_XINCREF(*buf);
+    return *buf;
+}
+
+/* s.recvmsg(bufsize[, ancbufsize[, flags]]) method */
+
+static PyObject *
+sock_recvmsg(PySocketSockObject *s, PyObject *args)
+{
+    Py_ssize_t bufsize, ancbufsize = 0;
+    int flags = 0;
+    struct iovec iov;
+    PyObject *buf = NULL, *retval = NULL;
+
+    if (!PyArg_ParseTuple(args, "n|ni:recvmsg", &bufsize, &ancbufsize, &flags))
+        return NULL;
+
+    if (bufsize < 0) {
+        PyErr_SetString(PyExc_ValueError, "negative buffer size in recvmsg()");
+        return NULL;
+    }
+    if ((buf = PyBytes_FromStringAndSize(NULL, bufsize)) == NULL)
+        return NULL;
+    iov.iov_base = PyBytes_AS_STRING(buf);
+    iov.iov_len = bufsize;
+
+    /* Note that we're passing a pointer to *our pointer* to the bytes
+       object here (&buf); makeval_recvmsg() may incref the object, or
+       deallocate it and set our pointer to NULL. */
+    retval = sock_recvmsg_guts(s, &iov, 1, flags, ancbufsize,
+                               &makeval_recvmsg, &buf);
+    Py_XDECREF(buf);
+    return retval;
+}
+
+PyDoc_STRVAR(recvmsg_doc,
+"recvmsg(bufsize[, ancbufsize[, flags]]) -> (data, ancdata, msg_flags, address)\n\
+\n\
+Receive normal data (up to bufsize bytes) and ancillary data from the\n\
+socket.  The ancbufsize argument sets the size in bytes of the\n\
+internal buffer used to receive the ancillary data; it defaults to 0,\n\
+meaning that no ancillary data will be received.  Appropriate buffer\n\
+sizes for ancillary data can be calculated using CMSG_SPACE() or\n\
+CMSG_LEN(), and items which do not fit into the buffer might be\n\
+truncated or discarded.  The flags argument defaults to 0 and has the\n\
+same meaning as for recv().\n\
+\n\
+The return value is a 4-tuple: (data, ancdata, msg_flags, address).\n\
+The data item is a bytes object holding the non-ancillary data\n\
+received.  The ancdata item is a list of zero or more tuples\n\
+(cmsg_level, cmsg_type, cmsg_data) representing the ancillary data\n\
+(control messages) received: cmsg_level and cmsg_type are integers\n\
+specifying the protocol level and protocol-specific type respectively,\n\
+and cmsg_data is a bytes object holding the associated data.  The\n\
+msg_flags item is the bitwise OR of various flags indicating\n\
+conditions on the received message; see your system documentation for\n\
+details.  If the receiving socket is unconnected, address is the\n\
+address of the sending socket, if available; otherwise, its value is\n\
+unspecified.\n\
+\n\
+If recvmsg() raises an exception after the system call returns, it\n\
+will first attempt to close any file descriptors received via the\n\
+SCM_RIGHTS mechanism.");
+
+
+static PyObject *
+makeval_recvmsg_into(ssize_t received, void *data)
+{
+    return PyLong_FromSsize_t(received);
+}
+
+/* s.recvmsg_into(buffers[, ancbufsize[, flags]]) method */
+
+static PyObject *
+sock_recvmsg_into(PySocketSockObject *s, PyObject *args)
+{
+    Py_ssize_t ancbufsize = 0;
+    int flags = 0;
+    struct iovec *iovs = NULL;
+    Py_ssize_t i, nitems, nbufs = 0;
+    Py_buffer *bufs = NULL;
+    PyObject *buffers_arg, *fast, *retval = NULL;
+
+    if (!PyArg_ParseTuple(args, "O|ni:recvmsg_into",
+                          &buffers_arg, &ancbufsize, &flags))
+        return NULL;
+
+    if ((fast = PySequence_Fast(buffers_arg,
+                                "recvmsg_into() argument 1 must be an "
+                                "iterable")) == NULL)
+        return NULL;
+    nitems = PySequence_Fast_GET_SIZE(fast);
+    if (nitems > INT_MAX) {
+        PyErr_SetString(socket_error, "recvmsg_into() argument 1 is too long");
+        goto finally;
+    }
+
+    /* Fill in an iovec for each item, and save the Py_buffer
+       structs to release afterwards. */
+    if (nitems > 0 && ((iovs = PyMem_New(struct iovec, nitems)) == NULL ||
+                       (bufs = PyMem_New(Py_buffer, nitems)) == NULL)) {
+        PyErr_NoMemory();
+        goto finally;
+    }
+    for (; nbufs < nitems; nbufs++) {
+        if (!PyArg_Parse(PySequence_Fast_GET_ITEM(fast, nbufs),
+                         "w*;recvmsg_into() argument 1 must be an iterable "
+                         "of single-segment read-write buffers",
+                         &bufs[nbufs]))
+            goto finally;
+        iovs[nbufs].iov_base = bufs[nbufs].buf;
+        iovs[nbufs].iov_len = bufs[nbufs].len;
+    }
+
+    retval = sock_recvmsg_guts(s, iovs, nitems, flags, ancbufsize,
+                               &makeval_recvmsg_into, NULL);
+finally:
+    for (i = 0; i < nbufs; i++)
+        PyBuffer_Release(&bufs[i]);
+    PyMem_Free(bufs);
+    PyMem_Free(iovs);
+    Py_DECREF(fast);
+    return retval;
+}
+
+PyDoc_STRVAR(recvmsg_into_doc,
+"recvmsg_into(buffers[, ancbufsize[, flags]]) -> (nbytes, ancdata, msg_flags, address)\n\
+\n\
+Receive normal data and ancillary data from the socket, scattering the\n\
+non-ancillary data into a series of buffers.  The buffers argument\n\
+must be an iterable of objects that export writable buffers\n\
+(e.g. bytearray objects); these will be filled with successive chunks\n\
+of the non-ancillary data until it has all been written or there are\n\
+no more buffers.  The ancbufsize argument sets the size in bytes of\n\
+the internal buffer used to receive the ancillary data; it defaults to\n\
+0, meaning that no ancillary data will be received.  Appropriate\n\
+buffer sizes for ancillary data can be calculated using CMSG_SPACE()\n\
+or CMSG_LEN(), and items which do not fit into the buffer might be\n\
+truncated or discarded.  The flags argument defaults to 0 and has the\n\
+same meaning as for recv().\n\
+\n\
+The return value is a 4-tuple: (nbytes, ancdata, msg_flags, address).\n\
+The nbytes item is the total number of bytes of non-ancillary data\n\
+written into the buffers.  The ancdata item is a list of zero or more\n\
+tuples (cmsg_level, cmsg_type, cmsg_data) representing the ancillary\n\
+data (control messages) received: cmsg_level and cmsg_type are\n\
+integers specifying the protocol level and protocol-specific type\n\
+respectively, and cmsg_data is a bytes object holding the associated\n\
+data.  The msg_flags item is the bitwise OR of various flags\n\
+indicating conditions on the received message; see your system\n\
+documentation for details.  If the receiving socket is unconnected,\n\
+address is the address of the sending socket, if available; otherwise,\n\
+its value is unspecified.\n\
+\n\
+If recvmsg_into() raises an exception after the system call returns,\n\
+it will first attempt to close any file descriptors received via the\n\
+SCM_RIGHTS mechanism.");
+#endif    /* CMSG_LEN */
+
+
 /* s.send(data [,flags]) method */
 
 static PyObject *
@@ -2826,6 +3276,237 @@ Like send(data, flags) but allows specif
 For IP sockets, the address is a pair (hostaddr, port).");
 
 
+/* The sendmsg() and recvmsg[_into]() methods require a working
+   CMSG_LEN().  See the comment near get_CMSG_LEN(). */
+#ifdef CMSG_LEN
+/* s.sendmsg(buffers[, ancdata[, flags[, address]]]) method */
+
+static PyObject *
+sock_sendmsg(PySocketSockObject *s, PyObject *args)
+{
+    Py_ssize_t i, ndataparts, ndatabufs = 0, ncmsgs, ncmsgbufs = 0;
+    Py_buffer *databufs = NULL;
+    struct iovec *iovs = NULL;
+    sock_addr_t addrbuf;
+    static const struct msghdr msg_blank;
+    struct msghdr msg;
+    struct cmsginfo {
+        int level;
+        int type;
+        Py_buffer data;
+    } *cmsgs = NULL;
+    void *controlbuf = NULL;
+    size_t controllen, controllen_last;
+    ssize_t bytes_sent = -1;
+    int addrlen, timeout, flags = 0;
+    PyObject *data_arg, *cmsg_arg = NULL, *addr_arg = NULL, *data_fast = NULL,
+        *cmsg_fast = NULL, *retval = NULL;
+
+    if (!PyArg_ParseTuple(args, "O|OiO:sendmsg",
+                          &data_arg, &cmsg_arg, &flags, &addr_arg))
+        return NULL;
+
+    msg = msg_blank;    /* Set all members to 0 or NULL */
+
+    /* Parse destination address. */
+    if (addr_arg != NULL && addr_arg != Py_None) {
+        if (!getsockaddrarg(s, addr_arg, SAS2SA(&addrbuf), &addrlen))
+            goto finally;
+        msg.msg_name = &addrbuf;
+        msg.msg_namelen = addrlen;
+    }
+
+    /* Fill in an iovec for each message part, and save the Py_buffer
+       structs to release afterwards. */
+    if ((data_fast = PySequence_Fast(data_arg,
+                                     "sendmsg() argument 1 must be an "
+                                     "iterable")) == NULL)
+        goto finally;
+    ndataparts = PySequence_Fast_GET_SIZE(data_fast);
+    if (ndataparts > INT_MAX) {
+        PyErr_SetString(socket_error, "sendmsg() argument 1 is too long");
+        goto finally;
+    }
+    msg.msg_iovlen = ndataparts;
+    if (ndataparts > 0 &&
+        ((msg.msg_iov = iovs = PyMem_New(struct iovec, ndataparts)) == NULL ||
+         (databufs = PyMem_New(Py_buffer, ndataparts)) == NULL)) {
+        PyErr_NoMemory();
+        goto finally;
+    }
+    for (; ndatabufs < ndataparts; ndatabufs++) {
+        if (!PyArg_Parse(PySequence_Fast_GET_ITEM(data_fast, ndatabufs),
+                         "y*;sendmsg() argument 1 must be an iterable of "
+                         "buffer-compatible objects",
+                         &databufs[ndatabufs]))
+            goto finally;
+        iovs[ndatabufs].iov_base = databufs[ndatabufs].buf;
+        iovs[ndatabufs].iov_len = databufs[ndatabufs].len;
+    }
+
+    if (cmsg_arg == NULL)
+        ncmsgs = 0;
+    else {
+        if ((cmsg_fast = PySequence_Fast(cmsg_arg,
+                                         "sendmsg() argument 2 must be an "
+                                         "iterable")) == NULL)
+            goto finally;
+        ncmsgs = PySequence_Fast_GET_SIZE(cmsg_fast);
+    }
+
+#ifndef CMSG_SPACE
+    if (ncmsgs > 1) {
+        PyErr_SetString(socket_error,
+                        "sending multiple control messages is not supported "
+                        "on this system");
+        goto finally;
+    }
+#endif
+    /* Save level, type and Py_buffer for each control message,
+       and calculate total size. */
+    if (ncmsgs > 0 && (cmsgs = PyMem_New(struct cmsginfo, ncmsgs)) == NULL) {
+        PyErr_NoMemory();
+        goto finally;
+    }
+    controllen = controllen_last = 0;
+    while (ncmsgbufs < ncmsgs) {
+        size_t bufsize, space;
+
+        if (!PyArg_Parse(PySequence_Fast_GET_ITEM(cmsg_fast, ncmsgbufs),
+                         "(iiy*):[sendmsg() ancillary data items]",
+                         &cmsgs[ncmsgbufs].level,
+                         &cmsgs[ncmsgbufs].type,
+                         &cmsgs[ncmsgbufs].data))
+            goto finally;
+        bufsize = cmsgs[ncmsgbufs++].data.len;
+
+#ifdef CMSG_SPACE
+        if (!get_CMSG_SPACE(bufsize, &space)) {
+#else
+        if (!get_CMSG_LEN(bufsize, &space)) {
+#endif
+            PyErr_SetString(socket_error, "ancillary data item too large");
+            goto finally;
+        }
+        controllen += space;
+        if (controllen > SOCKLEN_T_LIMIT || controllen < controllen_last) {
+            PyErr_SetString(socket_error, "too much ancillary data");
+            goto finally;
+        }
+        controllen_last = controllen;
+    }
+
+    /* Construct ancillary data block from control message info. */
+    if (ncmsgbufs > 0) {
+        struct cmsghdr *cmsgh = NULL;
+
+        if ((msg.msg_control = controlbuf =
+             PyMem_Malloc(controllen)) == NULL) {
+            PyErr_NoMemory();
+            goto finally;
+        }
+        msg.msg_controllen = controllen;
+
+        /* Need to zero out the buffer as a workaround for glibc's
+           CMSG_NXTHDR() implementation.  After getting the pointer to
+           the next header, it checks its (uninitialized) cmsg_len
+           member to see if the "message" fits in the buffer, and
+           returns NULL if it doesn't.  Zero-filling the buffer
+           ensures that that doesn't happen. */
+        memset(controlbuf, 0, controllen);
+
+        for (i = 0; i < ncmsgbufs; i++) {
+            size_t msg_len, data_len = cmsgs[i].data.len;
+            int enough_space = 0;
+
+            cmsgh = (i == 0) ? CMSG_FIRSTHDR(&msg) : CMSG_NXTHDR(&msg, cmsgh);
+            if (cmsgh == NULL) {
+                PyErr_Format(PyExc_RuntimeError,
+                             "unexpected NULL result from %s()",
+                             (i == 0) ? "CMSG_FIRSTHDR" : "CMSG_NXTHDR");
+                goto finally;
+            }
+            if (!get_CMSG_LEN(data_len, &msg_len)) {
+                PyErr_SetString(PyExc_RuntimeError,
+                                "item size out of range for CMSG_LEN()");
+                goto finally;
+            }
+            if (cmsg_min_space(&msg, cmsgh, msg_len)) {
+                size_t space;
+
+                cmsgh->cmsg_len = msg_len;
+                if (get_cmsg_data_space(&msg, cmsgh, &space))
+                    enough_space = (space >= data_len);
+            }
+            if (!enough_space) {
+                PyErr_SetString(PyExc_RuntimeError,
+                                "ancillary data does not fit in calculated "
+                                "space");
+                goto finally;
+            }
+            cmsgh->cmsg_level = cmsgs[i].level;
+            cmsgh->cmsg_type = cmsgs[i].type;
+            memcpy(CMSG_DATA(cmsgh), cmsgs[i].data.buf, data_len);
+        }
+    }
+
+    /* Make the system call. */
+    if (!IS_SELECTABLE(s)) {
+        select_error();
+        goto finally;
+    }
+
+    BEGIN_SELECT_LOOP(s)
+    Py_BEGIN_ALLOW_THREADS;
+    timeout = internal_select_ex(s, 1, interval);
+    if (!timeout)
+        bytes_sent = sendmsg(s->sock_fd, &msg, flags);
+    Py_END_ALLOW_THREADS;
+    if (timeout == 1) {
+        PyErr_SetString(socket_timeout, "timed out");
+        goto finally;
+    }
+    END_SELECT_LOOP(s)
+
+    if (bytes_sent < 0) {
+        s->errorhandler();
+        goto finally;
+    }
+    retval = PyLong_FromSsize_t(bytes_sent);
+
+finally:
+    PyMem_Free(controlbuf);
+    for (i = 0; i < ncmsgbufs; i++)
+        PyBuffer_Release(&cmsgs[i].data);
+    PyMem_Free(cmsgs);
+    Py_XDECREF(cmsg_fast);
+    for (i = 0; i < ndatabufs; i++)
+        PyBuffer_Release(&databufs[i]);
+    PyMem_Free(databufs);
+    PyMem_Free(iovs);
+    Py_XDECREF(data_fast);
+    return retval;
+}
+
+PyDoc_STRVAR(sendmsg_doc,
+"sendmsg(buffers[, ancdata[, flags[, address]]]) -> count\n\
+\n\
+Send normal and ancillary data to the socket, gathering the\n\
+non-ancillary data from a series of buffers and concatenating it into\n\
+a single message.  The buffers argument specifies the non-ancillary\n\
+data as an iterable of buffer-compatible objects (e.g. bytes objects).\n\
+The ancdata argument specifies the ancillary data (control messages)\n\
+as an iterable of zero or more tuples (cmsg_level, cmsg_type,\n\
+cmsg_data), where cmsg_level and cmsg_type are integers specifying the\n\
+protocol level and protocol-specific type respectively, and cmsg_data\n\
+is a buffer-compatible object holding the associated data.  The flags\n\
+argument defaults to 0 and has the same meaning as for send().  If\n\
+address is supplied and not None, it sets a destination address for\n\
+the message.  The return value is the number of bytes of non-ancillary\n\
+data sent.");
+#endif    /* CMSG_LEN */
+
+
 /* s.shutdown(how) method */
 
 static PyObject *
@@ -2952,6 +3633,14 @@ static PyMethodDef sock_methods[] = {
                       setsockopt_doc},
     {"shutdown",          (PyCFunction)sock_shutdown, METH_O,
                       shutdown_doc},
+#ifdef CMSG_LEN
+    {"recvmsg",           (PyCFunction)sock_recvmsg, METH_VARARGS,
+                      recvmsg_doc},
+    {"recvmsg_into",      (PyCFunction)sock_recvmsg_into, METH_VARARGS,
+                      recvmsg_into_doc,},
+    {"sendmsg",           (PyCFunction)sock_sendmsg, METH_VARARGS,
+                      sendmsg_doc},
+#endif
     {NULL,                      NULL}           /* sentinel */
 };
 
@@ -4377,6 +5066,68 @@ Returns the interface name corresponding
 #endif  /* HAVE_IF_NAMEINDEX */
 
 
+#ifdef CMSG_LEN
+/* Python interface to CMSG_LEN(length). */
+
+static PyObject *
+socket_CMSG_LEN(PyObject *self, PyObject *args)
+{
+    Py_ssize_t length;
+    size_t result;
+
+    if (!PyArg_ParseTuple(args, "n:CMSG_LEN", &length))
+        return NULL;
+    if (length < 0 || !get_CMSG_LEN(length, &result)) {
+        PyErr_Format(PyExc_OverflowError, "CMSG_LEN() argument out of range");
+        return NULL;
+    }
+    return PyLong_FromSize_t(result);
+}
+
+PyDoc_STRVAR(CMSG_LEN_doc,
+"CMSG_LEN(length) -> control message length\n\
+\n\
+Return the total length, without trailing padding, of an ancillary\n\
+data item with associated data of the given length.  This value can\n\
+often be used as the buffer size for recvmsg() to receive a single\n\
+item of ancillary data, but RFC 3542 requires portable applications to\n\
+use CMSG_SPACE() and thus include space for padding, even when the\n\
+item will be the last in the buffer.  Raises OverflowError if length\n\
+is outside the permissible range of values.");
+
+
+#ifdef CMSG_SPACE
+/* Python interface to CMSG_SPACE(length). */
+
+static PyObject *
+socket_CMSG_SPACE(PyObject *self, PyObject *args)
+{
+    Py_ssize_t length;
+    size_t result;
+
+    if (!PyArg_ParseTuple(args, "n:CMSG_SPACE", &length))
+        return NULL;
+    if (length < 0 || !get_CMSG_SPACE(length, &result)) {
+        PyErr_SetString(PyExc_OverflowError,
+                        "CMSG_SPACE() argument out of range");
+        return NULL;
+    }
+    return PyLong_FromSize_t(result);
+}
+
+PyDoc_STRVAR(CMSG_SPACE_doc,
+"CMSG_SPACE(length) -> buffer size\n\
+\n\
+Return the buffer size needed for recvmsg() to receive an ancillary\n\
+data item with associated data of the given length, along with any\n\
+trailing padding.  The buffer space needed to receive multiple items\n\
+is the sum of the CMSG_SPACE() values for their associated data\n\
+lengths.  Raises OverflowError if length is outside the permissible\n\
+range of values.");
+#endif    /* CMSG_SPACE */
+#endif    /* CMSG_LEN */
+
+
 /* List of functions exported by this module. */
 
 static PyMethodDef socket_methods[] = {
@@ -4440,6 +5191,14 @@ static PyMethodDef socket_methods[] = {
     {"if_indextoname", socket_if_indextoname,
      METH_O, if_indextoname_doc},
 #endif
+#ifdef CMSG_LEN
+    {"CMSG_LEN",                socket_CMSG_LEN,
+     METH_VARARGS, CMSG_LEN_doc},
+#ifdef CMSG_SPACE
+    {"CMSG_SPACE",              socket_CMSG_SPACE,
+     METH_VARARGS, CMSG_SPACE_doc},
+#endif
+#endif
     {NULL,                      NULL}            /* Sentinel */
 };
 
@@ -4927,6 +5686,15 @@ PyInit__socket(void)
 #ifdef  SO_SETFIB
     PyModule_AddIntConstant(m, "SO_SETFIB", SO_SETFIB);
 #endif
+#ifdef  SO_PASSCRED
+    PyModule_AddIntConstant(m, "SO_PASSCRED", SO_PASSCRED);
+#endif
+#ifdef  SO_PEERCRED
+    PyModule_AddIntConstant(m, "SO_PEERCRED", SO_PEERCRED);
+#endif
+#ifdef  LOCAL_PEERCRED
+    PyModule_AddIntConstant(m, "LOCAL_PEERCRED", LOCAL_PEERCRED);
+#endif
 
     /* Maximum number of connections for "listen" */
 #ifdef  SOMAXCONN
@@ -4935,6 +5703,17 @@ PyInit__socket(void)
     PyModule_AddIntConstant(m, "SOMAXCONN", 5); /* Common value */
 #endif
 
+    /* Ancilliary message types */
+#ifdef  SCM_RIGHTS
+    PyModule_AddIntConstant(m, "SCM_RIGHTS", SCM_RIGHTS);
+#endif
+#ifdef  SCM_CREDENTIALS
+    PyModule_AddIntConstant(m, "SCM_CREDENTIALS", SCM_CREDENTIALS);
+#endif
+#ifdef  SCM_CREDS
+    PyModule_AddIntConstant(m, "SCM_CREDS", SCM_CREDS);
+#endif
+
     /* Flags for send, recv */
 #ifdef  MSG_OOB
     PyModule_AddIntConstant(m, "MSG_OOB", MSG_OOB);
@@ -4966,6 +5745,33 @@ PyInit__socket(void)
 #ifdef  MSG_ETAG
     PyModule_AddIntConstant(m, "MSG_ETAG", MSG_ETAG);
 #endif
+#ifdef  MSG_NOSIGNAL
+    PyModule_AddIntConstant(m, "MSG_NOSIGNAL", MSG_NOSIGNAL);
+#endif
+#ifdef  MSG_NOTIFICATION
+    PyModule_AddIntConstant(m, "MSG_NOTIFICATION", MSG_NOTIFICATION);
+#endif
+#ifdef  MSG_CMSG_CLOEXEC
+    PyModule_AddIntConstant(m, "MSG_CMSG_CLOEXEC", MSG_CMSG_CLOEXEC);
+#endif
+#ifdef  MSG_ERRQUEUE
+    PyModule_AddIntConstant(m, "MSG_ERRQUEUE", MSG_ERRQUEUE);
+#endif
+#ifdef  MSG_CONFIRM
+    PyModule_AddIntConstant(m, "MSG_CONFIRM", MSG_CONFIRM);
+#endif
+#ifdef  MSG_MORE
+    PyModule_AddIntConstant(m, "MSG_MORE", MSG_MORE);
+#endif
+#ifdef  MSG_EOF
+    PyModule_AddIntConstant(m, "MSG_EOF", MSG_EOF);
+#endif
+#ifdef  MSG_BCAST
+    PyModule_AddIntConstant(m, "MSG_BCAST", MSG_BCAST);
+#endif
+#ifdef  MSG_MCAST
+    PyModule_AddIntConstant(m, "MSG_MCAST", MSG_MCAST);
+#endif
 
     /* Protocol level and numbers, usable for [gs]etsockopt */
 #ifdef  SOL_SOCKET
@@ -5105,6 +5911,9 @@ PyInit__socket(void)
 #ifdef  IPPROTO_VRRP
     PyModule_AddIntConstant(m, "IPPROTO_VRRP", IPPROTO_VRRP);
 #endif
+#ifdef  IPPROTO_SCTP
+    PyModule_AddIntConstant(m, "IPPROTO_SCTP", IPPROTO_SCTP);
+#endif
 #ifdef  IPPROTO_BIP
     PyModule_AddIntConstant(m, "IPPROTO_BIP", IPPROTO_BIP);
 #endif
-------------- next part --------------
# HG changeset patch
# User David Watson <vcs at dbwatson.ukfsn.org>, Heiko Wundram
# Date 1307303051 -3600
# Branch 2.7
# Node ID 3788da99ca221287c595729e1301988815e5a943
# Parent  6a4b67e8530972470e41a18b7dcf035b101ee26c
Issue #6560: support sendmsg() and recvmsg() on sockets.
Patch by David Watson and Heiko Wundram.

diff --git a/Doc/library/socket.rst b/Doc/library/socket.rst
--- a/Doc/library/socket.rst
+++ b/Doc/library/socket.rst
@@ -165,6 +165,7 @@ The module :mod:`socket` exports the fol
           SOMAXCONN
           MSG_*
           SOL_*
+          SCM_*
           IPPROTO_*
           IPPORT_*
           INADDR_*
@@ -486,6 +487,49 @@ The module :mod:`socket` exports the fol
    .. versionadded:: 2.3
 
 
+..
+   XXX: Are sendmsg(), recvmsg() and CMSG_*() available on any
+   non-Unix platforms?  The old (obsolete?) 4.2BSD form of the
+   interface, in which struct msghdr has no msg_control or
+   msg_controllen members, is not currently supported.
+
+.. function:: CMSG_LEN(length)
+
+   Return the total length, without trailing padding, of an ancillary
+   data item with associated data of the given *length*.  This value
+   can often be used as the buffer size for :meth:`~socket.recvmsg` to
+   receive a single item of ancillary data, but :rfc:`3542` requires
+   portable applications to use :func:`CMSG_SPACE` and thus include
+   space for padding, even when the item will be the last in the
+   buffer.  Raises :exc:`OverflowError` if *length* is outside the
+   permissible range of values.
+
+   Availability: most Unix platforms, possibly others.
+
+   .. versionadded:: XXX
+
+
+.. function:: CMSG_SPACE(length)
+
+   Return the buffer size needed for :meth:`~socket.recvmsg` to
+   receive an ancillary data item with associated data of the given
+   *length*, along with any trailing padding.  The buffer space needed
+   to receive multiple items is the sum of the :func:`CMSG_SPACE`
+   values for their associated data lengths.  Raises
+   :exc:`OverflowError` if *length* is outside the permissible range
+   of values.
+
+   Note that some systems might support ancillary data without
+   providing this function.  Also note that setting the buffer size
+   using the results of this function may not precisely limit the
+   amount of ancillary data that can be received, since additional
+   data may be able to fit into the padding area.
+
+   Availability: most Unix platforms, possibly others.
+
+   .. versionadded:: XXX
+
+
 .. function:: getdefaulttimeout()
 
    Return the default timeout in floating seconds for new socket objects. A value
@@ -689,6 +733,109 @@ correspond to Unix system calls applicab
    to zero. (The format of *address* depends on the address family --- see above.)
 
 
+.. method:: socket.recvmsg(bufsize[, ancbufsize[, flags]])
+
+   Receive normal data (up to *bufsize* bytes) and ancillary data from
+   the socket.  The *ancbufsize* argument sets the size in bytes of
+   the internal buffer used to receive the ancillary data; it defaults
+   to 0, meaning that no ancillary data will be received.  Appropriate
+   buffer sizes for ancillary data can be calculated using
+   :func:`CMSG_SPACE` or :func:`CMSG_LEN`, and items which do not fit
+   into the buffer might be truncated or discarded.  The *flags*
+   argument defaults to 0 and has the same meaning as for
+   :meth:`recv`.
+
+   The return value is a 4-tuple: ``(data, ancdata, msg_flags,
+   address)``.  The *data* item is a :class:`bytes` object holding the
+   non-ancillary data received.  The *ancdata* item is a list of zero
+   or more tuples ``(cmsg_level, cmsg_type, cmsg_data)`` representing
+   the ancillary data (control messages) received: *cmsg_level* and
+   *cmsg_type* are integers specifying the protocol level and
+   protocol-specific type respectively, and *cmsg_data* is a
+   :class:`bytes` object holding the associated data.  The *msg_flags*
+   item is the bitwise OR of various flags indicating conditions on
+   the received message; see your system documentation for details.
+   If the receiving socket is unconnected, *address* is the address of
+   the sending socket, if available; otherwise, its value is
+   unspecified.
+
+   On some systems, :meth:`sendmsg` and :meth:`recvmsg` can be used to
+   pass file descriptors between processes over an :const:`AF_UNIX`
+   socket.  When this facility is used (it is often restricted to
+   :const:`SOCK_STREAM` sockets), :meth:`recvmsg` will return, in its
+   ancillary data, items of the form ``(socket.SOL_SOCKET,
+   socket.SCM_RIGHTS, fds)``, where *fds* is a :class:`bytes` object
+   representing the new file descriptors as a binary array of the
+   native C :ctype:`int` type.  If :meth:`recvmsg` raises an exception
+   after the system call returns, it will first attempt to close any
+   file descriptors received via this mechanism.
+
+   Some systems do not indicate the truncated length of ancillary data
+   items which have been only partially received.  If an item appears
+   to extend beyond the end of the buffer, :meth:`recvmsg` will issue
+   a :exc:`RuntimeWarning`, and will return the part of it which is
+   inside the buffer provided it has not been truncated before the
+   start of its associated data.
+
+   On systems which support the :const:`SCM_RIGHTS` mechanism, the
+   following function will receive up to *maxfds* file descriptors,
+   returning the message data and a list containing the descriptors
+   (while ignoring unexpected conditions such as unrelated control
+   messages being received).  See also :meth:`sendmsg`. ::
+
+      import socket, array
+
+      def recv_fds(sock, msglen, maxfds):
+          fds = array.array("i")   # Array of ints
+          msg, ancdata, flags, addr = sock.recvmsg(msglen, socket.CMSG_LEN(maxfds * fds.itemsize))
+          for cmsg_level, cmsg_type, cmsg_data in ancdata:
+              if (cmsg_level == socket.SOL_SOCKET and cmsg_type == socket.SCM_RIGHTS):
+                  # Append data, ignoring any truncated integers at the end.
+                  fds.fromstring(cmsg_data[:len(cmsg_data) - (len(cmsg_data) % fds.itemsize)])
+          return msg, list(fds)
+
+   Availability: most Unix platforms, possibly others.
+
+   .. versionadded:: XXX
+
+
+.. method:: socket.recvmsg_into(buffers[, ancbufsize[, flags]])
+
+   Receive normal data and ancillary data from the socket, behaving as
+   :meth:`recvmsg` would, but scatter the non-ancillary data into a
+   series of buffers instead of returning a new bytes object.  The
+   *buffers* argument must be an iterable of objects that export
+   writable buffers (e.g. :class:`bytearray` objects); these will be
+   filled with successive chunks of the non-ancillary data until it
+   has all been written or there are no more buffers.  The operating
+   system may set a limit (:func:`~os.sysconf` value ``SC_IOV_MAX``)
+   on the number of buffers that can be used.  The *ancbufsize* and
+   *flags* arguments have the same meaning as for :meth:`recvmsg`.
+
+   The return value is a 4-tuple: ``(nbytes, ancdata, msg_flags,
+   address)``, where *nbytes* is the total number of bytes of
+   non-ancillary data written into the buffers, and *ancdata*,
+   *msg_flags* and *address* are the same as for :meth:`recvmsg`.
+
+   Example::
+
+      >>> import socket
+      >>> s1, s2 = socket.socketpair()
+      >>> b1 = bytearray(b'----')
+      >>> b2 = bytearray(b'0123456789')
+      >>> b3 = bytearray(b'--------------')
+      >>> s1.send(b'Mary had a little lamb')
+      22
+      >>> s2.recvmsg_into([b1, memoryview(b2)[2:9], b3])
+      (22, [], 0, None)
+      >>> [b1, b2, b3]
+      [bytearray(b'Mary'), bytearray(b'01 had a 9'), bytearray(b'little lamb---')]
+
+   Availability: most Unix platforms, possibly others.
+
+   .. versionadded:: XXX
+
+
 .. method:: socket.recvfrom_into(buffer[, nbytes[, flags]])
 
    Receive data from the socket, writing it into *buffer* instead of  creating a
@@ -740,6 +887,41 @@ correspond to Unix system calls applicab
    above.)
 
 
+.. method:: socket.sendmsg(buffers[, ancdata[, flags[, address]]])
+
+   Send normal and ancillary data to the socket, gathering the
+   non-ancillary data from a series of buffers and concatenating it
+   into a single message.  The *buffers* argument specifies the
+   non-ancillary data as an iterable of buffer-compatible objects
+   (e.g. :class:`bytes` objects); the operating system may set a limit
+   (:func:`~os.sysconf` value ``SC_IOV_MAX``) on the number of buffers
+   that can be used.  The *ancdata* argument specifies the ancillary
+   data (control messages) as an iterable of zero or more tuples
+   ``(cmsg_level, cmsg_type, cmsg_data)``, where *cmsg_level* and
+   *cmsg_type* are integers specifying the protocol level and
+   protocol-specific type respectively, and *cmsg_data* is a
+   buffer-compatible object holding the associated data.  Note that
+   some systems (in particular, systems without :func:`CMSG_SPACE`)
+   might support sending only one control message per call.  The
+   *flags* argument defaults to 0 and has the same meaning as for
+   :meth:`send`.  If *address* is supplied and not ``None``, it sets a
+   destination address for the message.  The return value is the
+   number of bytes of non-ancillary data sent.
+
+   The following function sends the list of file descriptors *fds*
+   over an :const:`AF_UNIX` socket, on systems which support the
+   :const:`SCM_RIGHTS` mechanism.  See also :meth:`recvmsg`. ::
+
+      import socket, array
+
+      def send_fds(sock, msg, fds):
+          return sock.sendmsg([msg], [(socket.SOL_SOCKET, socket.SCM_RIGHTS, array.array("i", fds))])
+
+   Availability: most Unix platforms, possibly others.
+
+   .. versionadded:: XXX
+
+
 .. method:: socket.setblocking(flag)
 
    Set blocking or non-blocking mode of the socket: if *flag* is 0, the socket is
diff --git a/Lib/socket.py b/Lib/socket.py
--- a/Lib/socket.py
+++ b/Lib/socket.py
@@ -162,14 +162,15 @@ if sys.platform == "riscos":
 # All the method names that must be delegated to either the real socket
 # object or the _closedsocket object.
 _delegate_methods = ("recv", "recvfrom", "recv_into", "recvfrom_into",
-                     "send", "sendto")
+                     "send", "sendto", "sendmsg", "recvmsg", "recvmsg_into")
 
 class _closedsocket(object):
     __slots__ = []
     def _dummy(*args):
         raise error(EBADF, 'Bad file descriptor')
     # All _delegate_methods must also be initialized here.
-    send = recv = recv_into = sendto = recvfrom = recvfrom_into = _dummy
+    send = recv = recv_into = sendto = recvfrom = recvfrom_into = sendmsg = \
+           recvmsg = recvmsg_into = _dummy
     __getattr__ = _dummy
 
 # Wrapper around platform socket objects. This implements
diff --git a/Lib/ssl.py b/Lib/ssl.py
--- a/Lib/ssl.py
+++ b/Lib/ssl.py
@@ -208,6 +208,13 @@ class SSLSocket(socket):
         else:
             return self._sock.sendto(data, flags_or_addr, addr)
 
+    def sendmsg(self, *args, **kwargs):
+        if self._sslobj:
+            raise ValueError("sendmsg not allowed on instances of %s" %
+                             self.__class__)
+        else:
+            return self._sock.sendmsg(*args, **kwargs)
+
     def sendall(self, data, flags=0):
         if self._sslobj:
             if flags != 0:
@@ -264,6 +271,20 @@ class SSLSocket(socket):
         else:
             return self._sock.recvfrom_into(buffer, nbytes, flags)
 
+    def recvmsg(self, *args, **kwargs):
+        if self._sslobj:
+            raise ValueError("recvmsg not allowed on instances of %s" %
+                             self.__class__)
+        else:
+            return self._sock.recvmsg(*args, **kwargs)
+
+    def recvmsg_into(self, *args, **kwargs):
+        if self._sslobj:
+            raise ValueError("recvmsg_into not allowed on instances of %s" %
+                             self.__class__)
+        else:
+            return self._sock.recvmsg_into(*args, **kwargs)
+
     def pending(self):
         if self._sslobj:
             return self._sslobj.pending()
diff --git a/Lib/test/test_socket.py b/Lib/test/test_socket.py
--- a/Lib/test/test_socket.py
+++ b/Lib/test/test_socket.py
@@ -6,6 +6,8 @@ from test import test_support
 import errno
 import socket
 import select
+import tempfile
+import _testcapi
 import time
 import traceback
 import Queue
@@ -43,6 +45,9 @@ except ImportError:
 HOST = test_support.HOST
 MSG = 'Michael Gilfix was here\n'
 
+# Size in bytes of the int type
+SIZEOF_INT = array.array("i").itemsize
+
 class SocketTCPTest(unittest.TestCase):
 
     def setUp(self):
@@ -64,6 +69,28 @@ class SocketUDPTest(unittest.TestCase):
         self.serv.close()
         self.serv = None
 
+class ThreadSafeCleanupTestCase(unittest.TestCase):
+    """Subclass of unittest.TestCase with thread-safe cleanup methods.
+
+    This subclass protects the addCleanup() and doCleanups() methods
+    with a recursive lock.
+    """
+
+    if threading:
+        def __init__(self, *args, **kwargs):
+            super(ThreadSafeCleanupTestCase, self).__init__(*args, **kwargs)
+            self._cleanup_lock = threading.RLock()
+
+        def addCleanup(self, *args, **kwargs):
+            with self._cleanup_lock:
+                return super(ThreadSafeCleanupTestCase, self).addCleanup(
+                    *args, **kwargs)
+
+        def doCleanups(self, *args, **kwargs):
+            with self._cleanup_lock:
+                return super(ThreadSafeCleanupTestCase, self).doCleanups(
+                    *args, **kwargs)
+
 class ThreadableTest:
     """Threadable Test class
 
@@ -241,6 +268,243 @@ class SocketPairTest(unittest.TestCase, 
         ThreadableTest.clientTearDown(self)
 
 
+# The following classes are used by the sendmsg()/recvmsg() tests.
+# Combining, for instance, ConnectedStreamTestMixin and TCPTestBase
+# gives a drop-in replacement for SocketConnectedTest, but different
+# address families can be used, and the attributes serv_addr and
+# cli_addr will be set to the addresses of the endpoints.
+
+class SocketTestBase(unittest.TestCase):
+    """A base class for socket tests.
+
+    Subclasses must provide methods newSocket() to return a new socket
+    and bindSock(sock) to bind it to an unused address.
+
+    Creates a socket self.serv and sets self.serv_addr to its address.
+    """
+
+    def setUp(self):
+        self.serv = self.newSocket()
+        self.bindServer()
+
+    def bindServer(self):
+        """Bind server socket and set self.serv_addr to its address."""
+        self.bindSock(self.serv)
+        self.serv_addr = self.serv.getsockname()
+
+    def tearDown(self):
+        self.serv.close()
+        self.serv = None
+
+
+class SocketListeningTestMixin(SocketTestBase):
+    """Mixin to listen on the server socket."""
+
+    def setUp(self):
+        super(SocketListeningTestMixin, self).setUp()
+        self.serv.listen(1)
+
+
+class ThreadedSocketTestMixin(ThreadSafeCleanupTestCase, SocketTestBase,
+                              ThreadableTest):
+    """Mixin to add client socket and allow client/server tests.
+
+    Client socket is self.cli and its address is self.cli_addr.  See
+    ThreadableTest for usage information.
+    """
+
+    def __init__(self, *args, **kwargs):
+        super(ThreadedSocketTestMixin, self).__init__(*args, **kwargs)
+        ThreadableTest.__init__(self)
+
+    def clientSetUp(self):
+        self.cli = self.newClientSocket()
+        self.bindClient()
+
+    def newClientSocket(self):
+        """Return a new socket for use as client."""
+        return self.newSocket()
+
+    def bindClient(self):
+        """Bind client socket and set self.cli_addr to its address."""
+        self.bindSock(self.cli)
+        self.cli_addr = self.cli.getsockname()
+
+    def clientTearDown(self):
+        self.cli.close()
+        self.cli = None
+        ThreadableTest.clientTearDown(self)
+
+
+class ConnectedStreamTestMixin(SocketListeningTestMixin,
+                               ThreadedSocketTestMixin):
+    """Mixin to allow client/server stream tests with connected client.
+
+    Server's socket representing connection to client is self.cli_conn
+    and client's connection to server is self.serv_conn.  (Based on
+    SocketConnectedTest.)
+    """
+
+    def setUp(self):
+        super(ConnectedStreamTestMixin, self).setUp()
+        # Indicate explicitly we're ready for the client thread to
+        # proceed and then perform the blocking call to accept
+        self.serverExplicitReady()
+        conn, addr = self.serv.accept()
+        self.cli_conn = conn
+
+    def tearDown(self):
+        self.cli_conn.close()
+        self.cli_conn = None
+        super(ConnectedStreamTestMixin, self).tearDown()
+
+    def clientSetUp(self):
+        super(ConnectedStreamTestMixin, self).clientSetUp()
+        self.cli.connect(self.serv_addr)
+        self.serv_conn = self.cli
+
+    def clientTearDown(self):
+        self.serv_conn.close()
+        self.serv_conn = None
+        super(ConnectedStreamTestMixin, self).clientTearDown()
+
+
+class UnixSocketTestBase(SocketTestBase):
+    """Base class for Unix-domain socket tests."""
+
+    # This class is used for file descriptor passing tests, so we
+    # create the sockets in a private directory so that other users
+    # can't send anything that might be problematic for a privileged
+    # user running the tests.
+
+    def setUp(self):
+        self.dir_path = tempfile.mkdtemp()
+        self.addCleanup(os.rmdir, self.dir_path)
+        super(UnixSocketTestBase, self).setUp()
+
+    def bindSock(self, sock):
+        path = tempfile.mktemp(dir=self.dir_path)
+        sock.bind(path)
+        self.addCleanup(test_support.unlink, path)
+
+class UnixStreamBase(UnixSocketTestBase):
+    """Base class for Unix-domain SOCK_STREAM tests."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
+
+
+class InetTestBase(SocketTestBase):
+    """Base class for IPv4 socket tests."""
+
+    host = HOST
+
+    def setUp(self):
+        super(InetTestBase, self).setUp()
+        self.port = self.serv_addr[1]
+
+    def bindSock(self, sock):
+        test_support.bind_port(sock, host=self.host)
+
+class TCPTestBase(InetTestBase):
+    """Base class for TCP-over-IPv4 tests."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+
+class UDPTestBase(InetTestBase):
+    """Base class for UDP-over-IPv4 tests."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
+
+class SCTPStreamBase(InetTestBase):
+    """Base class for SCTP tests in one-to-one (SOCK_STREAM) mode."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_INET, socket.SOCK_STREAM,
+                             socket.IPPROTO_SCTP)
+
+
+class Inet6TestBase(InetTestBase):
+    """Base class for IPv6 socket tests."""
+
+    # Don't use "localhost" here - it may not have an IPv6 address
+    # assigned to it by default (e.g. in /etc/hosts), and if someone
+    # has assigned it an IPv4-mapped address, then it's unlikely to
+    # work with the full IPv6 API.
+    host = "::1"
+
+class UDP6TestBase(Inet6TestBase):
+    """Base class for UDP-over-IPv6 tests."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
+
+
+# Test-skipping decorators for use with ThreadableTest.
+
+def skipWithClientIf(condition, reason):
+    """Skip decorated test if condition is true, add client_skip decorator.
+
+    If the decorated object is not a class, sets its attribute
+    "client_skip" to a decorator which will return an empty function
+    if the test is to be skipped, or the original function if it is
+    not.  This can be used to avoid running the client part of a
+    skipped test when using ThreadableTest.
+    """
+    def client_pass(*args, **kwargs):
+        pass
+    def skipdec(obj):
+        retval = unittest.skip(reason)(obj)
+        if not isinstance(obj, type):
+            retval.client_skip = lambda f: client_pass
+        return retval
+    def noskipdec(obj):
+        if not (isinstance(obj, type) or hasattr(obj, "client_skip")):
+            obj.client_skip = lambda f: f
+        return obj
+    return skipdec if condition else noskipdec
+
+
+def requireAttrs(obj, *attributes):
+    """Skip decorated test if obj is missing any of the given attributes.
+
+    Sets client_skip attribute as skipWithClientIf() does.
+    """
+    missing = [name for name in attributes if not hasattr(obj, name)]
+    return skipWithClientIf(
+        missing, "don't have " + ", ".join(name for name in missing))
+
+
+def requireSocket(*args):
+    """Skip decorated test if a socket cannot be created with given arguments.
+
+    When an argument is given as a string, will use the value of that
+    attribute of the socket module, or skip the test if it doesn't
+    exist.  Sets client_skip attribute as skipWithClientIf() does.
+    """
+    err = None
+    missing = [obj for obj in args if
+               isinstance(obj, str) and not hasattr(socket, obj)]
+    if missing:
+        err = "don't have " + ", ".join(name for name in missing)
+    else:
+        callargs = [getattr(socket, obj) if isinstance(obj, str) else obj
+                    for obj in args]
+        try:
+            s = socket.socket(*callargs)
+        except socket.error as e:
+            # XXX: check errno?
+            err = str(e)
+        else:
+            s.close()
+    return skipWithClientIf(
+        err is not None,
+        "can't create socket({0}): {1}".format(
+            ", ".join(str(o) for o in args), err))
+
+
 #######################################################################
 ## Begin Tests
 
@@ -829,6 +1093,1840 @@ class BasicUDPTest(ThreadedUDPSocketTest
     def _testRecvFromNegative(self):
         self.cli.sendto(MSG, 0, (HOST, self.port))
 
+
+# Tests for the sendmsg()/recvmsg() interface.  Where possible, the
+# same test code is used with different families and types of socket
+# (e.g. stream, datagram), and tests using recvmsg() are repeated
+# using recvmsg_into().
+#
+# The generic test classes such as SendmsgTests and
+# RecvmsgGenericTests inherit from SendrecvmsgBase and expect to be
+# supplied with sockets cli_sock and serv_sock representing the
+# client's and the server's end of the connection respectively, and
+# attributes cli_addr and serv_addr holding their (numeric where
+# appropriate) addresses.
+#
+# The final concrete test classes combine these with subclasses of
+# SocketTestBase which set up client and server sockets of a specific
+# type, and with subclasses of SendrecvmsgBase such as
+# SendrecvmsgDgramBase and SendrecvmsgConnectedBase which map these
+# sockets to cli_sock and serv_sock and override the methods and
+# attributes of SendrecvmsgBase to fill in destination addresses if
+# needed when sending, check for specific flags in msg_flags, etc.
+#
+# RecvmsgIntoMixin provides a version of doRecvmsg() implemented using
+# recvmsg_into().
+
+# XXX: like the other datagram (UDP) tests in this module, the code
+# here assumes that datagram delivery on the local machine will be
+# reliable.
+
+class SendrecvmsgBase(ThreadSafeCleanupTestCase):
+    # Base class for sendmsg()/recvmsg() tests.
+
+    # Time in seconds to wait before considering a test failed, or
+    # None for no timeout.  Not all tests actually set a timeout.
+    fail_timeout = 3.0
+
+    def setUp(self):
+        self.misc_event = threading.Event()
+        super(SendrecvmsgBase, self).setUp()
+
+    def sendToServer(self, msg):
+        # Send msg to the server.
+        return self.cli_sock.send(msg)
+
+    # Tuple of alternative default arguments for sendmsg() when called
+    # via sendmsgToServer() (e.g. to include a destination address).
+    sendmsg_to_server_defaults = ()
+
+    def sendmsgToServer(self, *args):
+        # Call sendmsg() on self.cli_sock with the given arguments,
+        # filling in any arguments which are not supplied with the
+        # corresponding items of self.sendmsg_to_server_defaults, if
+        # any.
+        return self.cli_sock.sendmsg(
+            *(args + self.sendmsg_to_server_defaults[len(args):]))
+
+    def doRecvmsg(self, sock, bufsize, *args):
+        # Call recvmsg() on sock with given arguments and return its
+        # result.  Should be used for tests which can use either
+        # recvmsg() or recvmsg_into() - RecvmsgIntoMixin overrides
+        # this method with one which emulates it using recvmsg_into(),
+        # thus allowing the same test to be used for both methods.
+        result = sock.recvmsg(bufsize, *args)
+        self.registerRecvmsgResult(result)
+        return result
+
+    def registerRecvmsgResult(self, result):
+        # Called by doRecvmsg() with the return value of recvmsg() or
+        # recvmsg_into().  Can be overridden to arrange cleanup based
+        # on the returned ancillary data, for instance.
+        pass
+
+    def checkRecvmsgAddress(self, addr1, addr2):
+        # Called to compare the received address with the address of
+        # the peer.
+        self.assertEqual(addr1, addr2)
+
+    # Flags that are normally unset in msg_flags
+    msg_flags_common_unset = 0
+    for name in ("MSG_CTRUNC", "MSG_OOB"):
+        msg_flags_common_unset |= getattr(socket, name, 0)
+
+    # Flags that are normally set
+    msg_flags_common_set = 0
+
+    # Flags set when a complete record has been received (e.g. MSG_EOR
+    # for SCTP)
+    msg_flags_eor_indicator = 0
+
+    # Flags set when a complete record has not been received
+    # (e.g. MSG_TRUNC for datagram sockets)
+    msg_flags_non_eor_indicator = 0
+
+    def checkFlags(self, flags, eor=None, checkset=0, checkunset=0, ignore=0):
+        # Method to check the value of msg_flags returned by recvmsg[_into]().
+        #
+        # Checks that all bits in msg_flags_common_set attribute are
+        # set in "flags" and all bits in msg_flags_common_unset are
+        # unset.
+        #
+        # The "eor" argument specifies whether the flags should
+        # indicate that a full record (or datagram) has been received.
+        # If "eor" is None, no checks are done; otherwise, checks
+        # that:
+        #
+        #  * if "eor" is true, all bits in msg_flags_eor_indicator are
+        #    set and all bits in msg_flags_non_eor_indicator are unset
+        #
+        #  * if "eor" is false, all bits in msg_flags_non_eor_indicator
+        #    are set and all bits in msg_flags_eor_indicator are unset
+        #
+        # If "checkset" and/or "checkunset" are supplied, they require
+        # the given bits to be set or unset respectively, overriding
+        # what the attributes require for those bits.
+        #
+        # If any bits are set in "ignore", they will not be checked,
+        # regardless of the other inputs.
+        #
+        # Will raise Exception if the inputs require a bit to be both
+        # set and unset, and it is not ignored.
+
+        defaultset = self.msg_flags_common_set
+        defaultunset = self.msg_flags_common_unset
+
+        if eor:
+            defaultset |= self.msg_flags_eor_indicator
+            defaultunset |= self.msg_flags_non_eor_indicator
+        elif eor is not None:
+            defaultset |= self.msg_flags_non_eor_indicator
+            defaultunset |= self.msg_flags_eor_indicator
+
+        # Function arguments override defaults
+        defaultset &= ~checkunset
+        defaultunset &= ~checkset
+
+        # Merge arguments with remaining defaults, and check for conflicts
+        checkset |= defaultset
+        checkunset |= defaultunset
+        inboth = checkset & checkunset & ~ignore
+        if inboth:
+            raise Exception("contradictory set, unset requirements for flags "
+                            "{0:#x}".format(inboth))
+
+        # Compare with given msg_flags value
+        mask = (checkset | checkunset) & ~ignore
+        self.assertEqual(flags & mask, checkset & mask)
+
+
+class RecvmsgIntoMixin(SendrecvmsgBase):
+    # Mixin to implement doRecvmsg() using recvmsg_into().
+
+    def doRecvmsg(self, sock, bufsize, *args):
+        buf = bytearray(bufsize)
+        result = sock.recvmsg_into([buf], *args)
+        self.registerRecvmsgResult(result)
+        self.assertGreaterEqual(result[0], 0)
+        self.assertLessEqual(result[0], bufsize)
+        return (bytes(buf[:result[0]]),) + result[1:]
+
+
+class SendrecvmsgDgramFlagsBase(SendrecvmsgBase):
+    # Defines flags to be checked in msg_flags for datagram sockets.
+
+    @property
+    def msg_flags_non_eor_indicator(self):
+        return (super(SendrecvmsgDgramFlagsBase, self)
+                .msg_flags_non_eor_indicator) | socket.MSG_TRUNC
+
+
+class SendrecvmsgSCTPFlagsBase(SendrecvmsgBase):
+    # Defines flags to be checked in msg_flags for SCTP sockets.
+
+    @property
+    def msg_flags_eor_indicator(self):
+        return super(SendrecvmsgSCTPFlagsBase, self).msg_flags_eor_indicator | socket.MSG_EOR
+
+
+class SendrecvmsgConnectionlessBase(SendrecvmsgBase):
+    # Base class for tests on connectionless-mode sockets.  Users must
+    # supply sockets on attributes cli and serv to be mapped to
+    # cli_sock and serv_sock respectively.
+
+    @property
+    def serv_sock(self):
+        return self.serv
+
+    @property
+    def cli_sock(self):
+        return self.cli
+
+    @property
+    def sendmsg_to_server_defaults(self):
+        return ([], [], 0, self.serv_addr)
+
+    def sendToServer(self, msg):
+        return self.cli_sock.sendto(msg, self.serv_addr)
+
+
+class SendrecvmsgConnectedBase(SendrecvmsgBase):
+    # Base class for tests on connected sockets.  Users must supply
+    # sockets on attributes serv_conn and cli_conn (representing the
+    # connections *to* the server and the client), to be mapped to
+    # cli_sock and serv_sock respectively.
+
+    @property
+    def serv_sock(self):
+        return self.cli_conn
+
+    @property
+    def cli_sock(self):
+        return self.serv_conn
+
+    def checkRecvmsgAddress(self, addr1, addr2):
+        # Address is currently "unspecified" for a connected socket,
+        # so we don't examine it
+        pass
+
+
+class SendrecvmsgServerTimeoutBase(SendrecvmsgBase):
+    # Base class to set a timeout on server's socket.
+
+    def setUp(self):
+        super(SendrecvmsgServerTimeoutBase, self).setUp()
+        self.serv_sock.settimeout(self.fail_timeout)
+
+
+class SendmsgTests(SendrecvmsgServerTimeoutBase):
+    # Tests for sendmsg() which can use any socket type and do not
+    # involve recvmsg() or recvmsg_into().
+
+    def testSendmsg(self):
+        # Send a simple message with sendmsg().
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsg(self):
+        self.assertEqual(self.sendmsgToServer([MSG]), len(MSG))
+
+    def testSendmsgDataGenerator(self):
+        # Send from buffer obtained from a generator (not a sequence).
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgDataGenerator(self):
+        self.assertEqual(self.sendmsgToServer((o for o in [MSG])),
+                         len(MSG))
+
+    def testSendmsgAncillaryGenerator(self):
+        # Gather (empty) ancillary data from a generator.
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgAncillaryGenerator(self):
+        self.assertEqual(self.sendmsgToServer([MSG], (o for o in [])),
+                         len(MSG))
+
+    def testSendmsgArray(self):
+        # Send data from an array instead of the usual bytes object.
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgArray(self):
+        self.assertEqual(self.sendmsgToServer([array.array("B", MSG)]),
+                         len(MSG))
+
+    def testSendmsgGather(self):
+        # Send message data from more than one buffer (gather write).
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgGather(self):
+        self.assertEqual(self.sendmsgToServer([MSG[:3], MSG[3:]]), len(MSG))
+
+    def testSendmsgBadArgs(self):
+        # Check that sendmsg() rejects invalid arguments.
+        self.assertEqual(self.serv_sock.recv(1000), b"done")
+
+    def _testSendmsgBadArgs(self):
+        self.assertRaises(TypeError, self.cli_sock.sendmsg)
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          bytearray(b"not in an iterable"))
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          object())
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [object()])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG, object()])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], object())
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [], object())
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [], 0, object())
+        self.sendToServer(b"done")
+
+    def testSendmsgBadCmsg(self):
+        # Check that invalid ancillary data items are rejected.
+        self.assertEqual(self.serv_sock.recv(1000), b"done")
+
+    def _testSendmsgBadCmsg(self):
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [object()])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(object(), 0, b"data")])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, object(), b"data")])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, 0, object())])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, 0)])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, 0, b"data", 42)])
+        self.sendToServer(b"done")
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testSendmsgBadMultiCmsg(self):
+        # Check that invalid ancillary data items are rejected when
+        # more than one item is present.
+        self.assertEqual(self.serv_sock.recv(1000), b"done")
+
+    @testSendmsgBadMultiCmsg.client_skip
+    def _testSendmsgBadMultiCmsg(self):
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [0, 0, b""])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, 0, b""), object()])
+        self.sendToServer(b"done")
+
+    def testSendmsgExcessCmsgReject(self):
+        # Check that sendmsg() rejects excess ancillary data items
+        # when the number that can be sent is limited.
+        self.assertEqual(self.serv_sock.recv(1000), b"done")
+
+    def _testSendmsgExcessCmsgReject(self):
+        if not hasattr(socket, "CMSG_SPACE"):
+            # Can only send one item
+            with self.assertRaises(socket.error) as cm:
+                self.sendmsgToServer([MSG], [(0, 0, b""), (0, 0, b"")])
+            self.assertIsNone(cm.exception.errno)
+        self.sendToServer(b"done")
+
+    def testSendmsgAfterClose(self):
+        # Check that sendmsg() fails on a closed socket.
+        pass
+
+    def _testSendmsgAfterClose(self):
+        self.cli_sock.close()
+        self.assertRaises(socket.error, self.sendmsgToServer, [MSG])
+
+
+class SendmsgStreamTests(SendmsgTests):
+    # Tests for sendmsg() which require a stream socket and do not
+    # involve recvmsg() or recvmsg_into().
+
+    def testSendmsgExplicitNoneAddr(self):
+        # Check that peer address can be specified as None.
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgExplicitNoneAddr(self):
+        self.assertEqual(self.sendmsgToServer([MSG], [], 0, None), len(MSG))
+
+    def testSendmsgTimeout(self):
+        # Check that timeout works with sendmsg().
+        self.assertEqual(self.serv_sock.recv(512), b"a"*512)
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+
+    def _testSendmsgTimeout(self):
+        try:
+            self.cli_sock.settimeout(0.03)
+            with self.assertRaises(socket.timeout):
+                while True:
+                    self.sendmsgToServer([b"a"*512])
+        finally:
+            self.misc_event.set()
+
+    # XXX: would be nice to have more tests for sendmsg flags argument.
+
+    # Linux supports MSG_DONTWAIT when sending, but in general, it
+    # only works when receiving.  Could add other platforms if they
+    # support it too.
+    @skipWithClientIf(sys.platform not in {"linux2"},
+                      "MSG_DONTWAIT not known to work on this platform when "
+                      "sending")
+    def testSendmsgDontWait(self):
+        # Check that MSG_DONTWAIT in flags causes non-blocking behaviour.
+        self.assertEqual(self.serv_sock.recv(512), b"a"*512)
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+
+    @testSendmsgDontWait.client_skip
+    def _testSendmsgDontWait(self):
+        try:
+            with self.assertRaises(socket.error) as cm:
+                while True:
+                    self.sendmsgToServer([b"a"*512], [], socket.MSG_DONTWAIT)
+            self.assertIn(cm.exception.errno,
+                          (errno.EAGAIN, errno.EWOULDBLOCK))
+        finally:
+            self.misc_event.set()
+
+
+class SendmsgConnectionlessTests(SendmsgTests):
+    # Tests for sendmsg() which require a connectionless-mode
+    # (e.g. datagram) socket, and do not involve recvmsg() or
+    # recvmsg_into().
+
+    def testSendmsgNoDestAddr(self):
+        # Check that sendmsg() fails when no destination address is
+        # given for unconnected socket.
+        pass
+
+    def _testSendmsgNoDestAddr(self):
+        self.assertRaises(socket.error, self.cli_sock.sendmsg,
+                          [MSG])
+        self.assertRaises(socket.error, self.cli_sock.sendmsg,
+                          [MSG], [], 0, None)
+
+
+class RecvmsgGenericTests(SendrecvmsgBase):
+    # Tests for recvmsg() which can also be emulated using
+    # recvmsg_into(), and can use any socket type.
+
+    def testRecvmsg(self):
+        # Receive a simple message with recvmsg[_into]().
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, len(MSG))
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsg(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgExplicitDefaults(self):
+        # Test recvmsg[_into]() with default arguments provided explicitly.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 0, 0)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgExplicitDefaults(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgShorter(self):
+        # Receive a message smaller than buffer.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG) + 42)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgShorter(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgTrunc(self):
+        # Receive part of message, check for truncation indicators.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG) - 3)
+        self.assertEqual(msg, MSG[:-3])
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=False)
+
+    def _testRecvmsgTrunc(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgShortAncillaryBuf(self):
+        # Test ancillary data buffer too small to hold any ancillary data.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 1)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgShortAncillaryBuf(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgLongAncillaryBuf(self):
+        # Test large ancillary data buffer.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 10240)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgLongAncillaryBuf(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgAfterClose(self):
+        # Check that recvmsg[_into]() fails on a closed socket.
+        self.serv_sock.close()
+        self.assertRaises(socket.error, self.doRecvmsg, self.serv_sock, 1024)
+
+    def _testRecvmsgAfterClose(self):
+        pass
+
+    def testRecvmsgTimeout(self):
+        # Check that timeout works.
+        try:
+            self.serv_sock.settimeout(0.03)
+            self.assertRaises(socket.timeout,
+                              self.doRecvmsg, self.serv_sock, len(MSG))
+        finally:
+            self.misc_event.set()
+
+    def _testRecvmsgTimeout(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+
+    @requireAttrs(socket, "MSG_PEEK")
+    def testRecvmsgPeek(self):
+        # Check that MSG_PEEK in flags enables examination of pending
+        # data without consuming it.
+
+        # Receive part of data with MSG_PEEK.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG) - 3, 0,
+                                                   socket.MSG_PEEK)
+        self.assertEqual(msg, MSG[:-3])
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        # Ignoring MSG_TRUNC here (so this test is the same for stream
+        # and datagram sockets).  Some wording in POSIX seems to
+        # suggest that it needn't be set when peeking, but that may
+        # just be a slip.
+        self.checkFlags(flags, eor=False,
+                        ignore=getattr(socket, "MSG_TRUNC", 0))
+
+        # Receive all data with MSG_PEEK.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 0,
+                                                   socket.MSG_PEEK)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+        # Check that the same data can still be received normally.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, len(MSG))
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    @testRecvmsgPeek.client_skip
+    def _testRecvmsgPeek(self):
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket.socket, "sendmsg")
+    def testRecvmsgFromSendmsg(self):
+        # Test receiving with recvmsg[_into]() when message is sent
+        # using sendmsg().
+        self.serv_sock.settimeout(self.fail_timeout)
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, len(MSG))
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    @testRecvmsgFromSendmsg.client_skip
+    def _testRecvmsgFromSendmsg(self):
+        self.assertEqual(self.sendmsgToServer([MSG[:3], MSG[3:]]), len(MSG))
+
+
+class RecvmsgGenericStreamTests(RecvmsgGenericTests):
+    # Tests which require a stream socket and can use either recvmsg()
+    # or recvmsg_into().
+
+    def testRecvmsgEOF(self):
+        # Receive end-of-stream indicator (b"", peer socket closed).
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, 1024)
+        self.assertEqual(msg, b"")
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=None) # Might not have end-of-record marker
+
+    def _testRecvmsgEOF(self):
+        self.cli_sock.close()
+
+    def testRecvmsgOverflow(self):
+        # Receive a message in more than one chunk.
+        seg1, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                    len(MSG) - 3)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=False)
+
+        seg2, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, 1024)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+        msg = seg1 + seg2
+        self.assertEqual(msg, MSG)
+
+    def _testRecvmsgOverflow(self):
+        self.sendToServer(MSG)
+
+
+class RecvmsgTests(RecvmsgGenericTests):
+    # Tests for recvmsg() which can use any socket type.
+
+    def testRecvmsgBadArgs(self):
+        # Check that recvmsg() rejects invalid arguments.
+        self.assertRaises(TypeError, self.serv_sock.recvmsg)
+        self.assertRaises(ValueError, self.serv_sock.recvmsg,
+                          -1, 0, 0)
+        self.assertRaises(ValueError, self.serv_sock.recvmsg,
+                          len(MSG), -1, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg,
+                          [bytearray(10)], 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg,
+                          object(), 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg,
+                          len(MSG), object(), 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg,
+                          len(MSG), 0, object())
+
+        msg, ancdata, flags, addr = self.serv_sock.recvmsg(len(MSG), 0, 0)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgBadArgs(self):
+        self.sendToServer(MSG)
+
+
+class RecvmsgIntoTests(RecvmsgIntoMixin, RecvmsgGenericTests):
+    # Tests for recvmsg_into() which can use any socket type.
+
+    def testRecvmsgIntoBadArgs(self):
+        # Check that recvmsg_into() rejects invalid arguments.
+        buf = bytearray(len(MSG))
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          len(MSG), 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          buf, 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [object()], 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [b"I'm not writable"], 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [buf, object()], 0, 0)
+        self.assertRaises(ValueError, self.serv_sock.recvmsg_into,
+                          [buf], -1, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [buf], object(), 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [buf], 0, object())
+
+        nbytes, ancdata, flags, addr = self.serv_sock.recvmsg_into([buf], 0, 0)
+        self.assertEqual(nbytes, len(MSG))
+        self.assertEqual(buf, bytearray(MSG))
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgIntoBadArgs(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgIntoGenerator(self):
+        # Receive into buffer obtained from a generator (not a sequence).
+        buf = bytearray(len(MSG))
+        nbytes, ancdata, flags, addr = self.serv_sock.recvmsg_into(
+            (o for o in [buf]))
+        self.assertEqual(nbytes, len(MSG))
+        self.assertEqual(buf, bytearray(MSG))
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgIntoGenerator(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgIntoArray(self):
+        # Receive into an array rather than the usual bytearray.
+        buf = array.array("B", [0] * len(MSG))
+        nbytes, ancdata, flags, addr = self.serv_sock.recvmsg_into([buf])
+        self.assertEqual(nbytes, len(MSG))
+        self.assertEqual(buf.tostring(), MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgIntoArray(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgIntoScatter(self):
+        # Receive into multiple buffers (scatter write).
+        b1 = bytearray(b"----")
+        b2 = bytearray(b"0123456789")
+        b3 = bytearray(b"--------------")
+        nbytes, ancdata, flags, addr = self.serv_sock.recvmsg_into(
+            [b1, memoryview(b2)[2:9], b3])
+        self.assertEqual(nbytes, len(b"Mary had a little lamb"))
+        self.assertEqual(b1, bytearray(b"Mary"))
+        self.assertEqual(b2, bytearray(b"01 had a 9"))
+        self.assertEqual(b3, bytearray(b"little lamb---"))
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgIntoScatter(self):
+        self.sendToServer(b"Mary had a little lamb")
+
+
+class CmsgMacroTests(unittest.TestCase):
+    # Test the functions CMSG_LEN() and CMSG_SPACE().  Tests
+    # assumptions used by sendmsg() and recvmsg[_into](), which share
+    # code with these functions.
+
+    # Match the definition in socketmodule.c
+    socklen_t_limit = min(0x7fffffff, _testcapi.INT_MAX)
+
+    @requireAttrs(socket, "CMSG_LEN")
+    def testCMSG_LEN(self):
+        # Test CMSG_LEN() with various valid and invalid values,
+        # checking the assumptions used by recvmsg() and sendmsg().
+        toobig = self.socklen_t_limit - socket.CMSG_LEN(0) + 1
+        values = list(range(257)) + list(range(toobig - 257, toobig))
+
+        # struct cmsghdr has at least three members, two of which are ints
+        self.assertGreater(socket.CMSG_LEN(0), array.array("i").itemsize * 2)
+        for n in values:
+            ret = socket.CMSG_LEN(n)
+            # This is how recvmsg() calculates the data size
+            self.assertEqual(ret - socket.CMSG_LEN(0), n)
+            self.assertLessEqual(ret, self.socklen_t_limit)
+
+        self.assertRaises(OverflowError, socket.CMSG_LEN, -1)
+        # sendmsg() shares code with these functions, and requires
+        # that it reject values over the limit.
+        self.assertRaises(OverflowError, socket.CMSG_LEN, toobig)
+        self.assertRaises(OverflowError, socket.CMSG_LEN, sys.maxsize)
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testCMSG_SPACE(self):
+        # Test CMSG_SPACE() with various valid and invalid values,
+        # checking the assumptions used by sendmsg().
+        toobig = self.socklen_t_limit - socket.CMSG_SPACE(1) + 1
+        values = list(range(257)) + list(range(toobig - 257, toobig))
+
+        last = socket.CMSG_SPACE(0)
+        # struct cmsghdr has at least three members, two of which are ints
+        self.assertGreater(last, array.array("i").itemsize * 2)
+        for n in values:
+            ret = socket.CMSG_SPACE(n)
+            self.assertGreaterEqual(ret, last)
+            self.assertGreaterEqual(ret, socket.CMSG_LEN(n))
+            self.assertGreaterEqual(ret, n + socket.CMSG_LEN(0))
+            self.assertLessEqual(ret, self.socklen_t_limit)
+            last = ret
+
+        self.assertRaises(OverflowError, socket.CMSG_SPACE, -1)
+        # sendmsg() shares code with these functions, and requires
+        # that it reject values over the limit.
+        self.assertRaises(OverflowError, socket.CMSG_SPACE, toobig)
+        self.assertRaises(OverflowError, socket.CMSG_SPACE, sys.maxsize)
+
+
+class SCMRightsTest(SendrecvmsgServerTimeoutBase):
+    # Tests for file descriptor passing on Unix-domain sockets.
+
+    # Invalid file descriptor value that's unlikely to evaluate to a
+    # real FD even if one of its bytes is replaced with a different
+    # value (which shouldn't actually happen).
+    badfd = -0x5555
+
+    def newFDs(self, n):
+        # Return a list of n file descriptors for newly-created files
+        # containing their list indices as ASCII numbers.
+        fds = []
+        for i in range(n):
+            fd, path = tempfile.mkstemp()
+            self.addCleanup(os.unlink, path)
+            self.addCleanup(os.close, fd)
+            os.write(fd, str(i).encode())
+            fds.append(fd)
+        return fds
+
+    def checkFDs(self, fds):
+        # Check that the file descriptors in the given list contain
+        # their correct list indices as ASCII numbers.
+        for n, fd in enumerate(fds):
+            os.lseek(fd, 0, os.SEEK_SET)
+            self.assertEqual(os.read(fd, 1024), str(n).encode())
+
+    def registerRecvmsgResult(self, result):
+        self.addCleanup(self.closeRecvmsgFDs, result)
+
+    def closeRecvmsgFDs(self, recvmsg_result):
+        # Close all file descriptors specified in the ancillary data
+        # of the given return value from recvmsg() or recvmsg_into().
+        for cmsg_level, cmsg_type, cmsg_data in recvmsg_result[1]:
+            if (cmsg_level == socket.SOL_SOCKET and
+                    cmsg_type == socket.SCM_RIGHTS):
+                fds = array.array("i")
+                fds.fromstring(cmsg_data[:
+                        len(cmsg_data) - (len(cmsg_data) % fds.itemsize)])
+                for fd in fds:
+                    os.close(fd)
+
+    def createAndSendFDs(self, n):
+        # Send n new file descriptors created by newFDs() to the
+        # server, with the constant MSG as the non-ancillary data.
+        self.assertEqual(
+            self.sendmsgToServer([MSG],
+                                 [(socket.SOL_SOCKET,
+                                   socket.SCM_RIGHTS,
+                                   array.array("i", self.newFDs(n)))]),
+            len(MSG))
+
+    def checkRecvmsgFDs(self, numfds, result, maxcmsgs=1, ignoreflags=0):
+        # Check that constant MSG was received with numfds file
+        # descriptors in a maximum of maxcmsgs control messages (which
+        # must contain only complete integers).  By default, check
+        # that MSG_CTRUNC is unset, but ignore any flags in
+        # ignoreflags.
+        msg, ancdata, flags, addr = result
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkunset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+        self.assertIsInstance(ancdata, list)
+        self.assertLessEqual(len(ancdata), maxcmsgs)
+        fds = array.array("i")
+        for item in ancdata:
+            self.assertIsInstance(item, tuple)
+            cmsg_level, cmsg_type, cmsg_data = item
+            self.assertEqual(cmsg_level, socket.SOL_SOCKET)
+            self.assertEqual(cmsg_type, socket.SCM_RIGHTS)
+            self.assertIsInstance(cmsg_data, bytes)
+            self.assertEqual(len(cmsg_data) % SIZEOF_INT, 0)
+            fds.fromstring(cmsg_data)
+
+        self.assertEqual(len(fds), numfds)
+        self.checkFDs(fds)
+
+    def testFDPassSimple(self):
+        # Pass a single FD (array read from bytes object).
+        self.checkRecvmsgFDs(1, self.doRecvmsg(self.serv_sock,
+                                               len(MSG), 10240))
+
+    def _testFDPassSimple(self):
+        self.assertEqual(
+            self.sendmsgToServer(
+                [MSG],
+                [(socket.SOL_SOCKET,
+                  socket.SCM_RIGHTS,
+                  array.array("i", self.newFDs(1)).tostring())]),
+            len(MSG))
+
+    def testMultipleFDPass(self):
+        # Pass multiple FDs in a single array.
+        self.checkRecvmsgFDs(4, self.doRecvmsg(self.serv_sock,
+                                               len(MSG), 10240))
+
+    def _testMultipleFDPass(self):
+        self.createAndSendFDs(4)
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testFDPassCMSG_SPACE(self):
+        # Test using CMSG_SPACE() to calculate ancillary buffer size.
+        self.checkRecvmsgFDs(
+            4, self.doRecvmsg(self.serv_sock, len(MSG),
+                              socket.CMSG_SPACE(4 * SIZEOF_INT)))
+
+    @testFDPassCMSG_SPACE.client_skip
+    def _testFDPassCMSG_SPACE(self):
+        self.createAndSendFDs(4)
+
+    def testFDPassCMSG_LEN(self):
+        # Test using CMSG_LEN() to calculate ancillary buffer size.
+        self.checkRecvmsgFDs(1,
+                             self.doRecvmsg(self.serv_sock, len(MSG),
+                                            socket.CMSG_LEN(4 * SIZEOF_INT)),
+                             # RFC 3542 says implementations may set
+                             # MSG_CTRUNC if there isn't enough space
+                             # for trailing padding.
+                             ignoreflags=socket.MSG_CTRUNC)
+
+    def _testFDPassCMSG_LEN(self):
+        self.createAndSendFDs(1)
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testFDPassSeparate(self):
+        # Pass two FDs in two separate arrays.  Arrays may be combined
+        # into a single control message by the OS.
+        self.checkRecvmsgFDs(2,
+                             self.doRecvmsg(self.serv_sock, len(MSG), 10240),
+                             maxcmsgs=2)
+
+    @testFDPassSeparate.client_skip
+    def _testFDPassSeparate(self):
+        fd0, fd1 = self.newFDs(2)
+        self.assertEqual(
+            self.sendmsgToServer([MSG], [(socket.SOL_SOCKET,
+                                          socket.SCM_RIGHTS,
+                                          array.array("i", [fd0])),
+                                         (socket.SOL_SOCKET,
+                                          socket.SCM_RIGHTS,
+                                          array.array("i", [fd1]))]),
+            len(MSG))
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testFDPassSeparateMinSpace(self):
+        # Pass two FDs in two separate arrays, receiving them into the
+        # minimum space for two arrays.
+        self.checkRecvmsgFDs(2,
+                             self.doRecvmsg(self.serv_sock, len(MSG),
+                                            socket.CMSG_SPACE(SIZEOF_INT) +
+                                            socket.CMSG_LEN(SIZEOF_INT)),
+                             maxcmsgs=2, ignoreflags=socket.MSG_CTRUNC)
+
+    @testFDPassSeparateMinSpace.client_skip
+    def _testFDPassSeparateMinSpace(self):
+        fd0, fd1 = self.newFDs(2)
+        self.assertEqual(
+            self.sendmsgToServer([MSG], [(socket.SOL_SOCKET,
+                                          socket.SCM_RIGHTS,
+                                          array.array("i", [fd0])),
+                                         (socket.SOL_SOCKET,
+                                          socket.SCM_RIGHTS,
+                                          array.array("i", [fd1]))]),
+            len(MSG))
+
+    def sendAncillaryIfPossible(self, msg, ancdata):
+        # Try to send msg and ancdata to server, but if the system
+        # call fails, just send msg with no ancillary data.
+        try:
+            nbytes = self.sendmsgToServer([msg], ancdata)
+        except socket.error as e:
+            # Check that it was the system call that failed
+            self.assertIsInstance(e.errno, int)
+            nbytes = self.sendmsgToServer([msg])
+        self.assertEqual(nbytes, len(msg))
+
+    def testFDPassEmpty(self):
+        # Try to pass an empty FD array.  Can receive either no array
+        # or an empty array.
+        self.checkRecvmsgFDs(0, self.doRecvmsg(self.serv_sock,
+                                               len(MSG), 10240),
+                             ignoreflags=socket.MSG_CTRUNC)
+
+    def _testFDPassEmpty(self):
+        self.sendAncillaryIfPossible(MSG, [(socket.SOL_SOCKET,
+                                            socket.SCM_RIGHTS,
+                                            b"")])
+
+    def testFDPassPartialInt(self):
+        # Try to pass a truncated FD array.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 10240)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, ignore=socket.MSG_CTRUNC)
+        self.assertLessEqual(len(ancdata), 1)
+        for cmsg_level, cmsg_type, cmsg_data in ancdata:
+            self.assertEqual(cmsg_level, socket.SOL_SOCKET)
+            self.assertEqual(cmsg_type, socket.SCM_RIGHTS)
+            self.assertLess(len(cmsg_data), SIZEOF_INT)
+
+    def _testFDPassPartialInt(self):
+        self.sendAncillaryIfPossible(
+            MSG,
+            [(socket.SOL_SOCKET,
+              socket.SCM_RIGHTS,
+              array.array("i", [self.badfd]).tostring()[:-1])])
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testFDPassPartialIntInMiddle(self):
+        # Try to pass two FD arrays, the first of which is truncated.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 10240)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, ignore=socket.MSG_CTRUNC)
+        self.assertLessEqual(len(ancdata), 2)
+        fds = array.array("i")
+        # Arrays may have been combined in a single control message
+        for cmsg_level, cmsg_type, cmsg_data in ancdata:
+            self.assertEqual(cmsg_level, socket.SOL_SOCKET)
+            self.assertEqual(cmsg_type, socket.SCM_RIGHTS)
+            fds.fromstring(cmsg_data[:
+                    len(cmsg_data) - (len(cmsg_data) % fds.itemsize)])
+        self.assertLessEqual(len(fds), 2)
+        self.checkFDs(fds)
+
+    @testFDPassPartialIntInMiddle.client_skip
+    def _testFDPassPartialIntInMiddle(self):
+        fd0, fd1 = self.newFDs(2)
+        self.sendAncillaryIfPossible(
+            MSG,
+            [(socket.SOL_SOCKET,
+              socket.SCM_RIGHTS,
+              array.array("i", [fd0, self.badfd]).tostring()[:-1]),
+             (socket.SOL_SOCKET,
+              socket.SCM_RIGHTS,
+              array.array("i", [fd1]))])
+
+    def checkTruncatedHeader(self, result, ignoreflags=0):
+        # Check that no ancillary data items are returned when data is
+        # truncated inside the cmsghdr structure.
+        msg, ancdata, flags, addr = result
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+    def testCmsgTruncNoBufSize(self):
+        # Check that no ancillary data is received when no buffer size
+        # is specified.
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG)),
+                                  # BSD seems to set MSG_CTRUNC only
+                                  # if an item has been partially
+                                  # received.
+                                  ignoreflags=socket.MSG_CTRUNC)
+
+    def _testCmsgTruncNoBufSize(self):
+        self.createAndSendFDs(1)
+
+    def testCmsgTrunc0(self):
+        # Check that no ancillary data is received when buffer size is 0.
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG), 0),
+                                  ignoreflags=socket.MSG_CTRUNC)
+
+    def _testCmsgTrunc0(self):
+        self.createAndSendFDs(1)
+
+    # Check that no ancillary data is returned for various non-zero
+    # (but still too small) buffer sizes.
+
+    def testCmsgTrunc1(self):
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG), 1))
+
+    def _testCmsgTrunc1(self):
+        self.createAndSendFDs(1)
+
+    def testCmsgTrunc2Int(self):
+        # The cmsghdr structure has at least three members, two of
+        # which are ints, so we still shouldn't see any ancillary
+        # data.
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG),
+                                                 SIZEOF_INT * 2))
+
+    def _testCmsgTrunc2Int(self):
+        self.createAndSendFDs(1)
+
+    def testCmsgTruncLen0Minus1(self):
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG),
+                                                 socket.CMSG_LEN(0) - 1))
+
+    def _testCmsgTruncLen0Minus1(self):
+        self.createAndSendFDs(1)
+
+    # The following tests try to truncate the control message in the
+    # middle of the FD array.
+
+    def checkTruncatedArray(self, ancbuf, maxdata, mindata=0):
+        # Check that file descriptor data is truncated to between
+        # mindata and maxdata bytes when received with buffer size
+        # ancbuf, and that any complete file descriptor numbers are
+        # valid.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), ancbuf)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC)
+
+        if mindata == 0 and ancdata == []:
+            return
+        self.assertEqual(len(ancdata), 1)
+        cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+        self.assertEqual(cmsg_level, socket.SOL_SOCKET)
+        self.assertEqual(cmsg_type, socket.SCM_RIGHTS)
+        self.assertGreaterEqual(len(cmsg_data), mindata)
+        self.assertLessEqual(len(cmsg_data), maxdata)
+        fds = array.array("i")
+        fds.fromstring(cmsg_data[:
+                len(cmsg_data) - (len(cmsg_data) % fds.itemsize)])
+        self.checkFDs(fds)
+
+    def testCmsgTruncLen0(self):
+        self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0), maxdata=0)
+
+    def _testCmsgTruncLen0(self):
+        self.createAndSendFDs(1)
+
+    def testCmsgTruncLen0Plus1(self):
+        self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0) + 1, maxdata=1)
+
+    def _testCmsgTruncLen0Plus1(self):
+        self.createAndSendFDs(2)
+
+    def testCmsgTruncLen1(self):
+        self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(SIZEOF_INT),
+                                 maxdata=SIZEOF_INT)
+
+    def _testCmsgTruncLen1(self):
+        self.createAndSendFDs(2)
+
+    def testCmsgTruncLen2Minus1(self):
+        self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(2 * SIZEOF_INT) - 1,
+                                 maxdata=(2 * SIZEOF_INT) - 1)
+
+    def _testCmsgTruncLen2Minus1(self):
+        self.createAndSendFDs(2)
+
+
+class RFC3542AncillaryTest(SendrecvmsgServerTimeoutBase):
+    # Test sendmsg() and recvmsg[_into]() using the ancillary data
+    # features of the RFC 3542 Advanced Sockets API for IPv6.
+    # Currently we can only handle certain data items (e.g. traffic
+    # class, hop limit, MTU discovery and fragmentation settings)
+    # without resorting to unportable means such as the struct module,
+    # but the tests here are aimed at testing the ancillary data
+    # handling in sendmsg() and recvmsg() rather than the IPv6 API
+    # itself.
+
+    # Test value to use when setting hop limit of packet
+    hop_limit = 2
+
+    # Test value to use when setting traffic class of packet.
+    # -1 means "use kernel default".
+    traffic_class = -1
+
+    def ancillaryMapping(self, ancdata):
+        # Given ancillary data list ancdata, return a mapping from
+        # pairs (cmsg_level, cmsg_type) to corresponding cmsg_data.
+        # Check that no (level, type) pair appears more than once.
+        d = {}
+        for cmsg_level, cmsg_type, cmsg_data in ancdata:
+            self.assertNotIn((cmsg_level, cmsg_type), d)
+            d[(cmsg_level, cmsg_type)] = cmsg_data
+        return d
+
+    def checkHopLimit(self, ancbufsize, maxhop=255, ignoreflags=0):
+        # Receive hop limit into ancbufsize bytes of ancillary data
+        # space.  Check that data is MSG, ancillary data is not
+        # truncated (but ignore any flags in ignoreflags), and hop
+        # limit is between 0 and maxhop inclusive.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), ancbufsize)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkunset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+        self.assertEqual(len(ancdata), 1)
+        self.assertIsInstance(ancdata[0], tuple)
+        cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+        self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+        self.assertEqual(cmsg_type, socket.IPV6_HOPLIMIT)
+        self.assertIsInstance(cmsg_data, bytes)
+        self.assertEqual(len(cmsg_data), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(cmsg_data)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], maxhop)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testRecvHopLimit(self):
+        # Test receiving the packet hop limit as ancillary data.
+        self.checkHopLimit(ancbufsize=10240)
+
+    @testRecvHopLimit.client_skip
+    def _testRecvHopLimit(self):
+        # Need to wait until server has asked to receive ancillary
+        # data, as implementations are not required to buffer it
+        # otherwise.
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testRecvHopLimitCMSG_SPACE(self):
+        # Test receiving hop limit, using CMSG_SPACE to calculate buffer size.
+        self.checkHopLimit(ancbufsize=socket.CMSG_SPACE(SIZEOF_INT))
+
+    @testRecvHopLimitCMSG_SPACE.client_skip
+    def _testRecvHopLimitCMSG_SPACE(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    # Could test receiving into buffer sized using CMSG_LEN, but RFC
+    # 3542 says portable applications must provide space for trailing
+    # padding.  Implementations may set MSG_CTRUNC if there isn't
+    # enough space for the padding.
+
+    @requireAttrs(socket.socket, "sendmsg")
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSetHopLimit(self):
+        # Test setting hop limit on outgoing packet and receiving it
+        # at the other end.
+        self.checkHopLimit(ancbufsize=10240, maxhop=self.hop_limit)
+
+    @testSetHopLimit.client_skip
+    def _testSetHopLimit(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.assertEqual(
+            self.sendmsgToServer([MSG],
+                                 [(socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT,
+                                   array.array("i", [self.hop_limit]))]),
+            len(MSG))
+
+    def checkTrafficClassAndHopLimit(self, ancbufsize, maxhop=255,
+                                     ignoreflags=0):
+        # Receive traffic class and hop limit into ancbufsize bytes of
+        # ancillary data space.  Check that data is MSG, ancillary
+        # data is not truncated (but ignore any flags in ignoreflags),
+        # and traffic class and hop limit are in range (hop limit no
+        # more than maxhop).
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVTCLASS, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), ancbufsize)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkunset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+        self.assertEqual(len(ancdata), 2)
+        ancmap = self.ancillaryMapping(ancdata)
+
+        tcdata = ancmap[(socket.IPPROTO_IPV6, socket.IPV6_TCLASS)]
+        self.assertEqual(len(tcdata), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(tcdata)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], 255)
+
+        hldata = ancmap[(socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT)]
+        self.assertEqual(len(hldata), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(hldata)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], maxhop)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testRecvTrafficClassAndHopLimit(self):
+        # Test receiving traffic class and hop limit as ancillary data.
+        self.checkTrafficClassAndHopLimit(ancbufsize=10240)
+
+    @testRecvTrafficClassAndHopLimit.client_skip
+    def _testRecvTrafficClassAndHopLimit(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testRecvTrafficClassAndHopLimitCMSG_SPACE(self):
+        # Test receiving traffic class and hop limit, using
+        # CMSG_SPACE() to calculate buffer size.
+        self.checkTrafficClassAndHopLimit(
+            ancbufsize=socket.CMSG_SPACE(SIZEOF_INT) * 2)
+
+    @testRecvTrafficClassAndHopLimitCMSG_SPACE.client_skip
+    def _testRecvTrafficClassAndHopLimitCMSG_SPACE(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket.socket, "sendmsg")
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSetTrafficClassAndHopLimit(self):
+        # Test setting traffic class and hop limit on outgoing packet,
+        # and receiving them at the other end.
+        self.checkTrafficClassAndHopLimit(ancbufsize=10240,
+                                          maxhop=self.hop_limit)
+
+    @testSetTrafficClassAndHopLimit.client_skip
+    def _testSetTrafficClassAndHopLimit(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.assertEqual(
+            self.sendmsgToServer([MSG],
+                                 [(socket.IPPROTO_IPV6, socket.IPV6_TCLASS,
+                                   array.array("i", [self.traffic_class])),
+                                  (socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT,
+                                   array.array("i", [self.hop_limit]))]),
+            len(MSG))
+
+    @requireAttrs(socket.socket, "sendmsg")
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testOddCmsgSize(self):
+        # Try to send ancillary data with first item one byte too
+        # long.  Fall back to sending with correct size if this fails,
+        # and check that second item was handled correctly.
+        self.checkTrafficClassAndHopLimit(ancbufsize=10240,
+                                          maxhop=self.hop_limit)
+
+    @testOddCmsgSize.client_skip
+    def _testOddCmsgSize(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        try:
+            nbytes = self.sendmsgToServer(
+                [MSG],
+                [(socket.IPPROTO_IPV6, socket.IPV6_TCLASS,
+                  array.array("i", [self.traffic_class]).tostring() + b"\x00"),
+                 (socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT,
+                  array.array("i", [self.hop_limit]))])
+        except socket.error as e:
+            self.assertIsInstance(e.errno, int)
+            nbytes = self.sendmsgToServer(
+                [MSG],
+                [(socket.IPPROTO_IPV6, socket.IPV6_TCLASS,
+                  array.array("i", [self.traffic_class])),
+                 (socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT,
+                  array.array("i", [self.hop_limit]))])
+            self.assertEqual(nbytes, len(MSG))
+
+    # Tests for proper handling of truncated ancillary data
+
+    def checkHopLimitTruncatedHeader(self, ancbufsize, ignoreflags=0):
+        # Receive hop limit into ancbufsize bytes of ancillary data
+        # space, which should be too small to contain the ancillary
+        # data header (if ancbufsize is None, pass no second argument
+        # to recvmsg()).  Check that data is MSG, MSG_CTRUNC is set
+        # (unless included in ignoreflags), and no ancillary data is
+        # returned.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.misc_event.set()
+        args = () if ancbufsize is None else (ancbufsize,)
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), *args)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testCmsgTruncNoBufSize(self):
+        # Check that no ancillary data is received when no ancillary
+        # buffer size is provided.
+        self.checkHopLimitTruncatedHeader(ancbufsize=None,
+                                          # BSD seems to set
+                                          # MSG_CTRUNC only if an item
+                                          # has been partially
+                                          # received.
+                                          ignoreflags=socket.MSG_CTRUNC)
+
+    @testCmsgTruncNoBufSize.client_skip
+    def _testCmsgTruncNoBufSize(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTrunc0(self):
+        # Check that no ancillary data is received when ancillary
+        # buffer size is zero.
+        self.checkHopLimitTruncatedHeader(ancbufsize=0,
+                                          ignoreflags=socket.MSG_CTRUNC)
+
+    @testSingleCmsgTrunc0.client_skip
+    def _testSingleCmsgTrunc0(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    # Check that no ancillary data is returned for various non-zero
+    # (but still too small) buffer sizes.
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTrunc1(self):
+        self.checkHopLimitTruncatedHeader(ancbufsize=1)
+
+    @testSingleCmsgTrunc1.client_skip
+    def _testSingleCmsgTrunc1(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTrunc2Int(self):
+        self.checkHopLimitTruncatedHeader(ancbufsize=2 * SIZEOF_INT)
+
+    @testSingleCmsgTrunc2Int.client_skip
+    def _testSingleCmsgTrunc2Int(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTruncLen0Minus1(self):
+        self.checkHopLimitTruncatedHeader(ancbufsize=socket.CMSG_LEN(0) - 1)
+
+    @testSingleCmsgTruncLen0Minus1.client_skip
+    def _testSingleCmsgTruncLen0Minus1(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTruncInData(self):
+        # Test truncation of a control message inside its associated
+        # data.  The message may be returned with its data truncated,
+        # or not returned at all.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(
+            self.serv_sock, len(MSG), socket.CMSG_LEN(SIZEOF_INT) - 1)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC)
+
+        self.assertLessEqual(len(ancdata), 1)
+        if ancdata:
+            cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+            self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+            self.assertEqual(cmsg_type, socket.IPV6_HOPLIMIT)
+            self.assertLess(len(cmsg_data), SIZEOF_INT)
+
+    @testSingleCmsgTruncInData.client_skip
+    def _testSingleCmsgTruncInData(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    def checkTruncatedSecondHeader(self, ancbufsize, ignoreflags=0):
+        # Receive traffic class and hop limit into ancbufsize bytes of
+        # ancillary data space, which should be large enough to
+        # contain the first item, but too small to contain the header
+        # of the second.  Check that data is MSG, MSG_CTRUNC is set
+        # (unless included in ignoreflags), and only one ancillary
+        # data item is returned.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVTCLASS, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), ancbufsize)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+        self.assertEqual(len(ancdata), 1)
+        cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+        self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+        self.assertIn(cmsg_type, {socket.IPV6_TCLASS, socket.IPV6_HOPLIMIT})
+        self.assertEqual(len(cmsg_data), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(cmsg_data)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], 255)
+
+    # Try the above test with various buffer sizes.
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecondCmsgTrunc0(self):
+        self.checkTruncatedSecondHeader(socket.CMSG_SPACE(SIZEOF_INT),
+                                        ignoreflags=socket.MSG_CTRUNC)
+
+    @testSecondCmsgTrunc0.client_skip
+    def _testSecondCmsgTrunc0(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecondCmsgTrunc1(self):
+        self.checkTruncatedSecondHeader(socket.CMSG_SPACE(SIZEOF_INT) + 1)
+
+    @testSecondCmsgTrunc1.client_skip
+    def _testSecondCmsgTrunc1(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecondCmsgTrunc2Int(self):
+        self.checkTruncatedSecondHeader(socket.CMSG_SPACE(SIZEOF_INT) +
+                                        2 * SIZEOF_INT)
+
+    @testSecondCmsgTrunc2Int.client_skip
+    def _testSecondCmsgTrunc2Int(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecondCmsgTruncLen0Minus1(self):
+        self.checkTruncatedSecondHeader(socket.CMSG_SPACE(SIZEOF_INT) +
+                                        socket.CMSG_LEN(0) - 1)
+
+    @testSecondCmsgTruncLen0Minus1.client_skip
+    def _testSecondCmsgTruncLen0Minus1(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecomdCmsgTruncInData(self):
+        # Test truncation of the second of two control messages inside
+        # its associated data.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVTCLASS, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(
+            self.serv_sock, len(MSG),
+            socket.CMSG_SPACE(SIZEOF_INT) + socket.CMSG_LEN(SIZEOF_INT) - 1)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC)
+
+        cmsg_types = {socket.IPV6_TCLASS, socket.IPV6_HOPLIMIT}
+
+        cmsg_level, cmsg_type, cmsg_data = ancdata.pop(0)
+        self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+        cmsg_types.remove(cmsg_type)
+        self.assertEqual(len(cmsg_data), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(cmsg_data)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], 255)
+
+        if ancdata:
+            cmsg_level, cmsg_type, cmsg_data = ancdata.pop(0)
+            self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+            cmsg_types.remove(cmsg_type)
+            self.assertLess(len(cmsg_data), SIZEOF_INT)
+
+        self.assertEqual(ancdata, [])
+
+    @testSecomdCmsgTruncInData.client_skip
+    def _testSecomdCmsgTruncInData(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+
+# Derive concrete test classes for different socket types.
+
+class SendrecvmsgUDPTestBase(SendrecvmsgDgramFlagsBase,
+                             SendrecvmsgConnectionlessBase,
+                             ThreadedSocketTestMixin, UDPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgUDPTest(SendmsgConnectionlessTests, SendrecvmsgUDPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgUDPTest(RecvmsgTests, SendrecvmsgUDPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoUDPTest(RecvmsgIntoTests, SendrecvmsgUDPTestBase):
+    pass
+
+
+class SendrecvmsgUDP6TestBase(SendrecvmsgDgramFlagsBase,
+                              SendrecvmsgConnectionlessBase,
+                              ThreadedSocketTestMixin, UDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgUDP6Test(SendmsgConnectionlessTests, SendrecvmsgUDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgUDP6Test(RecvmsgTests, SendrecvmsgUDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoUDP6Test(RecvmsgIntoTests, SendrecvmsgUDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireAttrs(socket, "IPPROTO_IPV6")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgRFC3542AncillaryUDP6Test(RFC3542AncillaryTest,
+                                      SendrecvmsgUDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireAttrs(socket, "IPPROTO_IPV6")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoRFC3542AncillaryUDP6Test(RecvmsgIntoMixin,
+                                          RFC3542AncillaryTest,
+                                          SendrecvmsgUDP6TestBase):
+    pass
+
+
+class SendrecvmsgTCPTestBase(SendrecvmsgConnectedBase,
+                             ConnectedStreamTestMixin, TCPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgTCPTest(SendmsgStreamTests, SendrecvmsgTCPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgTCPTest(RecvmsgTests, RecvmsgGenericStreamTests,
+                     SendrecvmsgTCPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoTCPTest(RecvmsgIntoTests, RecvmsgGenericStreamTests,
+                         SendrecvmsgTCPTestBase):
+    pass
+
+
+class SendrecvmsgSCTPStreamTestBase(SendrecvmsgSCTPFlagsBase,
+                                    SendrecvmsgConnectedBase,
+                                    ConnectedStreamTestMixin, SCTPStreamBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at requireSocket("AF_INET", "SOCK_STREAM", "IPPROTO_SCTP")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgSCTPStreamTest(SendmsgStreamTests, SendrecvmsgSCTPStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at requireSocket("AF_INET", "SOCK_STREAM", "IPPROTO_SCTP")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgSCTPStreamTest(RecvmsgTests, RecvmsgGenericStreamTests,
+                            SendrecvmsgSCTPStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at requireSocket("AF_INET", "SOCK_STREAM", "IPPROTO_SCTP")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoSCTPStreamTest(RecvmsgIntoTests, RecvmsgGenericStreamTests,
+                                SendrecvmsgSCTPStreamTestBase):
+    pass
+
+
+class SendrecvmsgUnixStreamTestBase(SendrecvmsgConnectedBase,
+                                    ConnectedStreamTestMixin, UnixStreamBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at requireAttrs(socket, "AF_UNIX")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgUnixStreamTest(SendmsgStreamTests, SendrecvmsgUnixStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at requireAttrs(socket, "AF_UNIX")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgUnixStreamTest(RecvmsgTests, RecvmsgGenericStreamTests,
+                            SendrecvmsgUnixStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at requireAttrs(socket, "AF_UNIX")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoUnixStreamTest(RecvmsgIntoTests, RecvmsgGenericStreamTests,
+                                SendrecvmsgUnixStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg", "recvmsg")
+ at requireAttrs(socket, "AF_UNIX", "SOL_SOCKET", "SCM_RIGHTS")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgSCMRightsStreamTest(SCMRightsTest, SendrecvmsgUnixStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg", "recvmsg_into")
+ at requireAttrs(socket, "AF_UNIX", "SOL_SOCKET", "SCM_RIGHTS")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoSCMRightsStreamTest(RecvmsgIntoMixin, SCMRightsTest,
+                                     SendrecvmsgUnixStreamTestBase):
+    pass
+
+
+# Test interrupting the interruptible send/receive methods with a
+# signal when a timeout is set.  These tests avoid having multiple
+# threads alive during the test so that the OS cannot deliver the
+# signal to the wrong one.
+
+class InterruptedTimeoutBase(unittest.TestCase):
+    # Base class for interrupted send/receive tests.  Installs an
+    # empty handler for SIGALRM and removes it on teardown, along with
+    # any scheduled alarms.
+
+    def setUp(self):
+        super(InterruptedTimeoutBase, self).setUp()
+        orig_alrm_handler = signal.signal(signal.SIGALRM,
+                                          lambda signum, frame: None)
+        self.addCleanup(signal.signal, signal.SIGALRM, orig_alrm_handler)
+        self.addCleanup(self.setAlarm, 0)
+
+    # Timeout for socket operations
+    timeout = 4.0
+
+    # Provide setAlarm() method to schedule delivery of SIGALRM after
+    # given number of seconds, or cancel it if zero, and an
+    # appropriate time value to use.  Use setitimer() if available.
+    if hasattr(signal, "setitimer"):
+        alarm_time = 0.05
+
+        def setAlarm(self, seconds):
+            signal.setitimer(signal.ITIMER_REAL, seconds)
+    else:
+        # Old systems may deliver the alarm up to one second early
+        alarm_time = 2
+
+        def setAlarm(self, seconds):
+            signal.alarm(seconds)
+
+
+# Require siginterrupt() in order to ensure that system calls are
+# interrupted by default.
+ at requireAttrs(signal, "siginterrupt")
+ at unittest.skipUnless(hasattr(signal, "alarm") or hasattr(signal, "setitimer"),
+                     "Don't have signal.alarm or signal.setitimer")
+class InterruptedRecvTimeoutTest(InterruptedTimeoutBase, UDPTestBase):
+    # Test interrupting the recv*() methods with signals when a
+    # timeout is set.
+
+    def setUp(self):
+        super(InterruptedRecvTimeoutTest, self).setUp()
+        self.serv.settimeout(self.timeout)
+
+    def checkInterruptedRecv(self, func, *args, **kwargs):
+        # Check that func(*args, **kwargs) raises socket.error with an
+        # errno of EINTR when interrupted by a signal.
+        self.setAlarm(self.alarm_time)
+        with self.assertRaises(socket.error) as cm:
+            func(*args, **kwargs)
+        self.assertNotIsInstance(cm.exception, socket.timeout)
+        self.assertEqual(cm.exception.errno, errno.EINTR)
+
+    def testInterruptedRecvTimeout(self):
+        self.checkInterruptedRecv(self.serv.recv, 1024)
+
+    def testInterruptedRecvIntoTimeout(self):
+        self.checkInterruptedRecv(self.serv.recv_into, bytearray(1024))
+
+    def testInterruptedRecvfromTimeout(self):
+        self.checkInterruptedRecv(self.serv.recvfrom, 1024)
+
+    def testInterruptedRecvfromIntoTimeout(self):
+        self.checkInterruptedRecv(self.serv.recvfrom_into, bytearray(1024))
+
+    @requireAttrs(socket.socket, "recvmsg")
+    def testInterruptedRecvmsgTimeout(self):
+        self.checkInterruptedRecv(self.serv.recvmsg, 1024)
+
+    @requireAttrs(socket.socket, "recvmsg_into")
+    def testInterruptedRecvmsgIntoTimeout(self):
+        self.checkInterruptedRecv(self.serv.recvmsg_into, [bytearray(1024)])
+
+
+# Require siginterrupt() in order to ensure that system calls are
+# interrupted by default.
+ at requireAttrs(signal, "siginterrupt")
+ at unittest.skipUnless(hasattr(signal, "alarm") or hasattr(signal, "setitimer"),
+                     "Don't have signal.alarm or signal.setitimer")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class InterruptedSendTimeoutTest(InterruptedTimeoutBase,
+                                 ThreadSafeCleanupTestCase,
+                                 SocketListeningTestMixin, TCPTestBase):
+    # Test interrupting the interruptible send*() methods with signals
+    # when a timeout is set.
+
+    def setUp(self):
+        super(InterruptedSendTimeoutTest, self).setUp()
+        self.serv_conn = self.newSocket()
+        self.addCleanup(self.serv_conn.close)
+        # Use a thread to complete the connection, but wait for it to
+        # terminate before running the test, so that there is only one
+        # thread to accept the signal.
+        cli_thread = threading.Thread(target=self.doConnect)
+        cli_thread.start()
+        self.cli_conn, addr = self.serv.accept()
+        self.addCleanup(self.cli_conn.close)
+        cli_thread.join()
+        self.serv_conn.settimeout(self.timeout)
+
+    def doConnect(self):
+        self.serv_conn.connect(self.serv_addr)
+
+    def checkInterruptedSend(self, func, *args, **kwargs):
+        # Check that func(*args, **kwargs), run in a loop, raises
+        # socket.error with an errno of EINTR when interrupted by a
+        # signal.
+        with self.assertRaises(socket.error) as cm:
+            while True:
+                self.setAlarm(self.alarm_time)
+                func(*args, **kwargs)
+        self.assertNotIsInstance(cm.exception, socket.timeout)
+        self.assertEqual(cm.exception.errno, errno.EINTR)
+
+    def testInterruptedSendTimeout(self):
+        self.checkInterruptedSend(self.serv_conn.send, b"a"*512)
+
+    def testInterruptedSendtoTimeout(self):
+        # Passing an actual address here as Python's wrapper for
+        # sendto() doesn't allow passing a zero-length one; POSIX
+        # requires that the address is ignored since the socket is
+        # connection-mode, however.
+        self.checkInterruptedSend(self.serv_conn.sendto, b"a"*512,
+                                  self.serv_addr)
+
+    @requireAttrs(socket.socket, "sendmsg")
+    def testInterruptedSendmsgTimeout(self):
+        self.checkInterruptedSend(self.serv_conn.sendmsg, [b"a"*512])
+
+
 @unittest.skipUnless(thread, 'Threading required for this test.')
 class TCPCloserTest(ThreadedTCPSocketTest):
 
@@ -1609,6 +3707,31 @@ def test_main():
     if isTipcAvailable():
         tests.append(TIPCTest)
         tests.append(TIPCThreadableTest)
+    tests.extend([
+        CmsgMacroTests,
+        SendmsgUDPTest,
+        RecvmsgUDPTest,
+        RecvmsgIntoUDPTest,
+        SendmsgUDP6Test,
+        RecvmsgUDP6Test,
+        RecvmsgRFC3542AncillaryUDP6Test,
+        RecvmsgIntoRFC3542AncillaryUDP6Test,
+        RecvmsgIntoUDP6Test,
+        SendmsgTCPTest,
+        RecvmsgTCPTest,
+        RecvmsgIntoTCPTest,
+        SendmsgSCTPStreamTest,
+        RecvmsgSCTPStreamTest,
+        RecvmsgIntoSCTPStreamTest,
+        SendmsgUnixStreamTest,
+        RecvmsgUnixStreamTest,
+        RecvmsgIntoUnixStreamTest,
+        RecvmsgSCMRightsStreamTest,
+        RecvmsgIntoSCMRightsStreamTest,
+        # These are slow when setitimer() is not available
+        InterruptedRecvTimeoutTest,
+        InterruptedSendTimeoutTest,
+    ])
 
     thread_info = test_support.threading_setup()
     test_support.run_unittest(*tests)
diff --git a/Lib/test/test_ssl.py b/Lib/test/test_ssl.py
--- a/Lib/test/test_ssl.py
+++ b/Lib/test/test_ssl.py
@@ -188,8 +188,11 @@ class BasicSocketTests(unittest.TestCase
         self.assertRaises(socket.error, ss.recv_into, bytearray(b'x'))
         self.assertRaises(socket.error, ss.recvfrom, 1)
         self.assertRaises(socket.error, ss.recvfrom_into, bytearray(b'x'), 1)
+        self.assertRaises(socket.error, ss.recvmsg, 1)
+        self.assertRaises(socket.error, ss.recvmsg_into, [bytearray(b'x')])
         self.assertRaises(socket.error, ss.send, b'x')
         self.assertRaises(socket.error, ss.sendto, b'x', ('0.0.0.0', 0))
+        self.assertRaises(socket.error, ss.sendmsg, [b'x'])
 
 
 class NetworkedTests(unittest.TestCase):
@@ -1200,17 +1203,30 @@ else:
                     count, addr = s.recvfrom_into(b)
                     return b[:count]
 
+                def _recvmsg(*args, **kwargs):
+                    return s.recvmsg(*args, **kwargs)[0]
+
+                def _recvmsg_into(bufsize, *args, **kwargs):
+                    b = bytearray(bufsize)
+                    return bytes(b[:s.recvmsg_into([b], *args, **kwargs)[0]])
+
+                def _sendmsg(msg, *args, **kwargs):
+                    return s.sendmsg([msg])
+
                 # (name, method, whether to expect success, *args)
                 send_methods = [
                     ('send', s.send, True, []),
                     ('sendto', s.sendto, False, ["some.address"]),
+                    ('sendmsg', _sendmsg, False, []),
                     ('sendall', s.sendall, True, []),
                 ]
                 recv_methods = [
                     ('recv', s.recv, True, []),
                     ('recvfrom', s.recvfrom, False, ["some.address"]),
+                    ('recvmsg', _recvmsg, False, [100]),
                     ('recv_into', _recv_into, True, []),
                     ('recvfrom_into', _recvfrom_into, False, []),
+                    ('recvmsg_into', _recvmsg_into, False, [100]),
                 ]
                 data_prefix = u"PREFIX_"
 
diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -251,6 +251,7 @@ shutdown(how) -- shut down traffic in on
 #ifdef HAVE_SYS_TYPES_H
 #include <sys/types.h>
 #endif
+#include <unistd.h>
 
 /* Generic socket object definitions and includes */
 #define PySocket_BUILDING_SOCKET
@@ -456,6 +457,17 @@ static PyTypeObject sock_type;
 #include <sys/poll.h>
 #endif
 
+/* Largest value to try to store in a socklen_t (used when handling
+   ancillary data).  POSIX requires socklen_t to hold at least
+   (2**31)-1 and recommends against storing larger values, but
+   socklen_t was originally int in the BSD interface, so to be on the
+   safe side we use the smaller of (2**31)-1 and INT_MAX. */
+#if INT_MAX > 0x7fffffff
+#define SOCKLEN_T_LIMIT 0x7fffffff
+#else
+#define SOCKLEN_T_LIMIT INT_MAX
+#endif
+
 #ifdef Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE
 /* Platform can select file descriptors beyond FD_SETSIZE */
 #define IS_SELECTABLE(s) 1
@@ -1627,6 +1639,117 @@ getsockaddrlen(PySocketSockObject *s, so
 }
 
 
+/* Support functions for the sendmsg() and recvmsg[_into]() methods.
+   Currently, these methods are only compiled if the RFC 2292/3542
+   CMSG_LEN() macro is available.  Older systems seem to have used
+   sizeof(struct cmsghdr) + (length) where CMSG_LEN() is used now, so
+   it may be possible to define CMSG_LEN() that way if it's not
+   provided.  Some architectures might need extra padding after the
+   cmsghdr, however, and CMSG_LEN() would have to take account of
+   this. */
+#ifdef CMSG_LEN
+/* If length is in range, set *result to CMSG_LEN(length) and return
+   true; otherwise, return false. */
+static int
+get_CMSG_LEN(size_t length, size_t *result)
+{
+    size_t tmp;
+
+    if (length > (SOCKLEN_T_LIMIT - CMSG_LEN(0)))
+        return 0;
+    tmp = CMSG_LEN(length);
+    if (tmp > SOCKLEN_T_LIMIT || tmp < length)
+        return 0;
+    *result = tmp;
+    return 1;
+}
+
+#ifdef CMSG_SPACE
+/* If length is in range, set *result to CMSG_SPACE(length) and return
+   true; otherwise, return false. */
+static int
+get_CMSG_SPACE(size_t length, size_t *result)
+{
+    size_t tmp;
+
+    /* Use CMSG_SPACE(1) here in order to take account of the padding
+       necessary before *and* after the data. */
+    if (length > (SOCKLEN_T_LIMIT - CMSG_SPACE(1)))
+        return 0;
+    tmp = CMSG_SPACE(length);
+    if (tmp > SOCKLEN_T_LIMIT || tmp < length)
+        return 0;
+    *result = tmp;
+    return 1;
+}
+#endif
+
+/* Return true iff msg->msg_controllen is valid, cmsgh is a valid
+   pointer in msg->msg_control with at least "space" bytes after it,
+   and its cmsg_len member inside the buffer. */
+static int
+cmsg_min_space(struct msghdr *msg, struct cmsghdr *cmsgh, size_t space)
+{
+    size_t cmsg_offset;
+    static const size_t cmsg_len_end = (offsetof(struct cmsghdr, cmsg_len) +
+                                        sizeof(cmsgh->cmsg_len));
+
+    if (cmsgh == NULL || msg->msg_control == NULL || msg->msg_controllen < 0)
+        return 0;
+    if (space < cmsg_len_end)
+        space = cmsg_len_end;
+    cmsg_offset = (char *)cmsgh - (char *)msg->msg_control;
+    return (cmsg_offset <= (size_t)-1 - space &&
+            cmsg_offset + space <= msg->msg_controllen);
+}
+
+/* If pointer CMSG_DATA(cmsgh) is in buffer msg->msg_control, set
+   *space to number of bytes following it in the buffer and return
+   true; otherwise, return false.  Assumes cmsgh, msg->msg_control and
+   msg->msg_controllen are valid. */
+static int
+get_cmsg_data_space(struct msghdr *msg, struct cmsghdr *cmsgh, size_t *space)
+{
+    size_t data_offset;
+    char *data_ptr;
+
+    if ((data_ptr = (char *)CMSG_DATA(cmsgh)) == NULL)
+        return 0;
+    data_offset = data_ptr - (char *)msg->msg_control;
+    if (data_offset > msg->msg_controllen)
+        return 0;
+    *space = msg->msg_controllen - data_offset;
+    return 1;
+}
+
+/* If cmsgh is invalid or not contained in the buffer pointed to by
+   msg->msg_control, return -1.  If cmsgh is valid and its associated
+   data is entirely contained in the buffer, set *data_len to the
+   length of the associated data and return 0.  If only part of the
+   associated data is contained in the buffer but cmsgh is otherwise
+   valid, set *data_len to the length contained in the buffer and
+   return 1. */
+static int
+get_cmsg_data_len(struct msghdr *msg, struct cmsghdr *cmsgh, size_t *data_len)
+{
+    size_t space, cmsg_data_len;
+
+    if (!cmsg_min_space(msg, cmsgh, CMSG_LEN(0)) ||
+        cmsgh->cmsg_len < CMSG_LEN(0))
+        return -1;
+    cmsg_data_len = cmsgh->cmsg_len - CMSG_LEN(0);
+    if (!get_cmsg_data_space(msg, cmsgh, &space))
+        return -1;
+    if (space >= cmsg_data_len) {
+        *data_len = cmsg_data_len;
+        return 0;
+    }
+    *data_len = space;
+    return 1;
+}
+#endif    /* CMSG_LEN */
+
+
 /* s.accept() method */
 
 static PyObject *
@@ -2697,6 +2820,333 @@ PyDoc_STRVAR(recvfrom_into_doc,
 Like recv_into(buffer[, nbytes[, flags]]) but also return the sender's address info.");
 
 
+/* The sendmsg() and recvmsg[_into]() methods require a working
+   CMSG_LEN().  See the comment near get_CMSG_LEN(). */
+#ifdef CMSG_LEN
+/*
+ * Call recvmsg() with the supplied iovec structures, flags, and
+ * ancillary data buffer size (controllen).  Returns the tuple return
+ * value for recvmsg() or recvmsg_into(), with the first item provided
+ * by the supplied makeval() function.  makeval() will be called with
+ * the length read and makeval_data as arguments, and must return a
+ * new reference (which will be decrefed if there is a subsequent
+ * error).  On error, closes any file descriptors received via
+ * SCM_RIGHTS.
+ */
+static PyObject *
+sock_recvmsg_guts(PySocketSockObject *s, struct iovec *iov, int iovlen,
+                  int flags, Py_ssize_t controllen,
+                  PyObject *(*makeval)(ssize_t, void *), void *makeval_data)
+{
+    ssize_t bytes_received = -1;
+    int timeout;
+    sock_addr_t addrbuf;
+    socklen_t addrbuflen;
+    static const struct msghdr msg_blank;
+    struct msghdr msg;
+    PyObject *cmsg_list = NULL, *retval = NULL;
+    void *controlbuf = NULL;
+    struct cmsghdr *cmsgh;
+    size_t cmsgdatalen = 0;
+    int cmsg_status;
+
+    /* XXX: POSIX says that msg_name and msg_namelen "shall be
+       ignored" when the socket is connected (Linux fills them in
+       anyway for AF_UNIX sockets at least).  Normally msg_namelen
+       seems to be set to 0 if there's no address, but try to
+       initialize msg_name to something that won't be mistaken for a
+       real address if that doesn't happen. */
+    if (!getsockaddrlen(s, &addrbuflen))
+        return NULL;
+    memset(&addrbuf, 0, addrbuflen);
+    SAS2SA(&addrbuf)->sa_family = AF_UNSPEC;
+
+    if (controllen < 0 || controllen > SOCKLEN_T_LIMIT) {
+        PyErr_SetString(PyExc_ValueError,
+                        "invalid ancillary data buffer length");
+        return NULL;
+    }
+    if (controllen > 0 && (controlbuf = PyMem_Malloc(controllen)) == NULL)
+        return PyErr_NoMemory();
+
+    /* Make the system call. */
+    if (!IS_SELECTABLE(s)) {
+        select_error();
+        goto finally;
+    }
+
+    msg = msg_blank;    /* Set all members to 0 or NULL */
+    msg.msg_name = SAS2SA(&addrbuf);
+    msg.msg_namelen = addrbuflen;
+    msg.msg_iov = iov;
+    msg.msg_iovlen = iovlen;
+    msg.msg_control = controlbuf;
+    msg.msg_controllen = controllen;
+
+    Py_BEGIN_ALLOW_THREADS;
+    timeout = internal_select(s, 0);
+    if (!timeout)
+        bytes_received = recvmsg(s->sock_fd, &msg, flags);
+    Py_END_ALLOW_THREADS;
+
+    if (timeout == 1) {
+        PyErr_SetString(socket_timeout, "timed out");
+        goto finally;
+    }
+
+    if (bytes_received < 0) {
+        s->errorhandler();
+        goto finally;
+    }
+
+    /* Make list of (level, type, data) tuples from control messages. */
+    if ((cmsg_list = PyList_New(0)) == NULL)
+        goto err_closefds;
+    /* Check for empty ancillary data as old CMSG_FIRSTHDR()
+       implementations didn't do so. */
+    for (cmsgh = ((msg.msg_controllen > 0) ? CMSG_FIRSTHDR(&msg) : NULL);
+         cmsgh != NULL; cmsgh = CMSG_NXTHDR(&msg, cmsgh)) {
+        PyObject *bytes, *tuple;
+        int tmp;
+
+        cmsg_status = get_cmsg_data_len(&msg, cmsgh, &cmsgdatalen);
+        if (cmsg_status != 0) {
+            if (PyErr_WarnEx(PyExc_RuntimeWarning,
+                             "received malformed or improperly-truncated "
+                             "ancillary data", 1) == -1)
+                goto err_closefds;
+        }
+        if (cmsg_status < 0)
+            break;
+        if (cmsgdatalen > PY_SSIZE_T_MAX) {
+            PyErr_SetString(socket_error, "control message too long");
+            goto err_closefds;
+        }
+
+        bytes = PyBytes_FromStringAndSize((char *)CMSG_DATA(cmsgh),
+                                          cmsgdatalen);
+        tuple = Py_BuildValue("iiN", (int)cmsgh->cmsg_level,
+                              (int)cmsgh->cmsg_type, bytes);
+        if (tuple == NULL)
+            goto err_closefds;
+        tmp = PyList_Append(cmsg_list, tuple);
+        Py_DECREF(tuple);
+        if (tmp != 0)
+            goto err_closefds;
+
+        if (cmsg_status != 0)
+            break;
+    }
+
+    retval = Py_BuildValue("NOiN",
+                           (*makeval)(bytes_received, makeval_data),
+                           cmsg_list,
+                           (int)msg.msg_flags,
+                           makesockaddr(s->sock_fd, SAS2SA(&addrbuf),
+                                        ((msg.msg_namelen > addrbuflen) ?
+                                         addrbuflen : msg.msg_namelen),
+                                        s->sock_proto));
+    if (retval == NULL)
+        goto err_closefds;
+
+finally:
+    Py_XDECREF(cmsg_list);
+    PyMem_Free(controlbuf);
+    return retval;
+
+err_closefds:
+#ifdef SCM_RIGHTS
+    /* Close all descriptors coming from SCM_RIGHTS, so they don't leak. */
+    for (cmsgh = ((msg.msg_controllen > 0) ? CMSG_FIRSTHDR(&msg) : NULL);
+         cmsgh != NULL; cmsgh = CMSG_NXTHDR(&msg, cmsgh)) {
+        cmsg_status = get_cmsg_data_len(&msg, cmsgh, &cmsgdatalen);
+        if (cmsg_status < 0)
+            break;
+        if (cmsgh->cmsg_level == SOL_SOCKET &&
+            cmsgh->cmsg_type == SCM_RIGHTS) {
+            size_t numfds;
+            int *fdp;
+
+            numfds = cmsgdatalen / sizeof(int);
+            fdp = (int *)CMSG_DATA(cmsgh);
+            while (numfds-- > 0)
+                close(*fdp++);
+        }
+        if (cmsg_status != 0)
+            break;
+    }
+#endif /* SCM_RIGHTS */
+    goto finally;
+}
+
+
+static PyObject *
+makeval_recvmsg(ssize_t received, void *data)
+{
+    PyObject **buf = data;
+
+    if (received < PyBytes_GET_SIZE(*buf))
+        _PyBytes_Resize(buf, received);
+    Py_XINCREF(*buf);
+    return *buf;
+}
+
+/* s.recvmsg(bufsize[, ancbufsize[, flags]]) method */
+
+static PyObject *
+sock_recvmsg(PySocketSockObject *s, PyObject *args)
+{
+    Py_ssize_t bufsize, ancbufsize = 0;
+    int flags = 0;
+    struct iovec iov;
+    PyObject *buf = NULL, *retval = NULL;
+
+    if (!PyArg_ParseTuple(args, "n|ni:recvmsg", &bufsize, &ancbufsize, &flags))
+        return NULL;
+
+    if (bufsize < 0) {
+        PyErr_SetString(PyExc_ValueError, "negative buffer size in recvmsg()");
+        return NULL;
+    }
+    if ((buf = PyBytes_FromStringAndSize(NULL, bufsize)) == NULL)
+        return NULL;
+    iov.iov_base = PyBytes_AS_STRING(buf);
+    iov.iov_len = bufsize;
+
+    /* Note that we're passing a pointer to *our pointer* to the bytes
+       object here (&buf); makeval_recvmsg() may incref the object, or
+       deallocate it and set our pointer to NULL. */
+    retval = sock_recvmsg_guts(s, &iov, 1, flags, ancbufsize,
+                               &makeval_recvmsg, &buf);
+    Py_XDECREF(buf);
+    return retval;
+}
+
+PyDoc_STRVAR(recvmsg_doc,
+"recvmsg(bufsize[, ancbufsize[, flags]]) -> (data, ancdata, msg_flags, address)\n\
+\n\
+Receive normal data (up to bufsize bytes) and ancillary data from the\n\
+socket.  The ancbufsize argument sets the size in bytes of the\n\
+internal buffer used to receive the ancillary data; it defaults to 0,\n\
+meaning that no ancillary data will be received.  Appropriate buffer\n\
+sizes for ancillary data can be calculated using CMSG_SPACE() or\n\
+CMSG_LEN(), and items which do not fit into the buffer might be\n\
+truncated or discarded.  The flags argument defaults to 0 and has the\n\
+same meaning as for recv().\n\
+\n\
+The return value is a 4-tuple: (data, ancdata, msg_flags, address).\n\
+The data item is a bytes object holding the non-ancillary data\n\
+received.  The ancdata item is a list of zero or more tuples\n\
+(cmsg_level, cmsg_type, cmsg_data) representing the ancillary data\n\
+(control messages) received: cmsg_level and cmsg_type are integers\n\
+specifying the protocol level and protocol-specific type respectively,\n\
+and cmsg_data is a bytes object holding the associated data.  The\n\
+msg_flags item is the bitwise OR of various flags indicating\n\
+conditions on the received message; see your system documentation for\n\
+details.  If the receiving socket is unconnected, address is the\n\
+address of the sending socket, if available; otherwise, its value is\n\
+unspecified.\n\
+\n\
+If recvmsg() raises an exception after the system call returns, it\n\
+will first attempt to close any file descriptors received via the\n\
+SCM_RIGHTS mechanism.");
+
+
+static PyObject *
+makeval_recvmsg_into(ssize_t received, void *data)
+{
+    return PyInt_FromSsize_t(received);
+}
+
+/* s.recvmsg_into(buffers[, ancbufsize[, flags]]) method */
+
+static PyObject *
+sock_recvmsg_into(PySocketSockObject *s, PyObject *args)
+{
+    Py_ssize_t ancbufsize = 0;
+    int flags = 0;
+    struct iovec *iovs = NULL;
+    Py_ssize_t i, nitems, nbufs = 0;
+    Py_buffer *bufs = NULL;
+    PyObject *buffers_arg, *fast, *retval = NULL;
+
+    if (!PyArg_ParseTuple(args, "O|ni:recvmsg_into",
+                          &buffers_arg, &ancbufsize, &flags))
+        return NULL;
+
+    if ((fast = PySequence_Fast(buffers_arg,
+                                "recvmsg_into() argument 1 must be an "
+                                "iterable")) == NULL)
+        return NULL;
+    nitems = PySequence_Fast_GET_SIZE(fast);
+    if (nitems > INT_MAX) {
+        PyErr_SetString(socket_error, "recvmsg_into() argument 1 is too long");
+        goto finally;
+    }
+
+    /* Fill in an iovec for each item, and save the Py_buffer
+       structs to release afterwards. */
+    if (nitems > 0 && ((iovs = PyMem_New(struct iovec, nitems)) == NULL ||
+                       (bufs = PyMem_New(Py_buffer, nitems)) == NULL)) {
+        PyErr_NoMemory();
+        goto finally;
+    }
+    for (; nbufs < nitems; nbufs++) {
+        if (!PyArg_Parse(PySequence_Fast_GET_ITEM(fast, nbufs),
+                         "w*;recvmsg_into() argument 1 must be an iterable "
+                         "of single-segment read-write buffers",
+                         &bufs[nbufs]))
+            goto finally;
+        iovs[nbufs].iov_base = bufs[nbufs].buf;
+        iovs[nbufs].iov_len = bufs[nbufs].len;
+    }
+
+    retval = sock_recvmsg_guts(s, iovs, nitems, flags, ancbufsize,
+                               &makeval_recvmsg_into, NULL);
+finally:
+    for (i = 0; i < nbufs; i++)
+        PyBuffer_Release(&bufs[i]);
+    PyMem_Free(bufs);
+    PyMem_Free(iovs);
+    Py_DECREF(fast);
+    return retval;
+}
+
+PyDoc_STRVAR(recvmsg_into_doc,
+"recvmsg_into(buffers[, ancbufsize[, flags]]) -> (nbytes, ancdata, msg_flags, address)\n\
+\n\
+Receive normal data and ancillary data from the socket, scattering the\n\
+non-ancillary data into a series of buffers.  The buffers argument\n\
+must be an iterable of objects that export writable buffers\n\
+(e.g. bytearray objects); these will be filled with successive chunks\n\
+of the non-ancillary data until it has all been written or there are\n\
+no more buffers.  The ancbufsize argument sets the size in bytes of\n\
+the internal buffer used to receive the ancillary data; it defaults to\n\
+0, meaning that no ancillary data will be received.  Appropriate\n\
+buffer sizes for ancillary data can be calculated using CMSG_SPACE()\n\
+or CMSG_LEN(), and items which do not fit into the buffer might be\n\
+truncated or discarded.  The flags argument defaults to 0 and has the\n\
+same meaning as for recv().\n\
+\n\
+The return value is a 4-tuple: (nbytes, ancdata, msg_flags, address).\n\
+The nbytes item is the total number of bytes of non-ancillary data\n\
+written into the buffers.  The ancdata item is a list of zero or more\n\
+tuples (cmsg_level, cmsg_type, cmsg_data) representing the ancillary\n\
+data (control messages) received: cmsg_level and cmsg_type are\n\
+integers specifying the protocol level and protocol-specific type\n\
+respectively, and cmsg_data is a bytes object holding the associated\n\
+data.  The msg_flags item is the bitwise OR of various flags\n\
+indicating conditions on the received message; see your system\n\
+documentation for details.  If the receiving socket is unconnected,\n\
+address is the address of the sending socket, if available; otherwise,\n\
+its value is unspecified.\n\
+\n\
+If recvmsg_into() raises an exception after the system call returns,\n\
+it will first attempt to close any file descriptors received via the\n\
+SCM_RIGHTS mechanism.");
+#endif    /* CMSG_LEN */
+
+
 /* s.send(data [,flags]) method */
 
 static PyObject *
@@ -2883,6 +3333,236 @@ Like send(data, flags) but allows specif
 For IP sockets, the address is a pair (hostaddr, port).");
 
 
+/* The sendmsg() and recvmsg[_into]() methods require a working
+   CMSG_LEN().  See the comment near get_CMSG_LEN(). */
+#ifdef CMSG_LEN
+/* s.sendmsg(buffers[, ancdata[, flags[, address]]]) method */
+
+static PyObject *
+sock_sendmsg(PySocketSockObject *s, PyObject *args)
+{
+    Py_ssize_t i, ndataparts, ndatabufs = 0, ncmsgs, ncmsgbufs = 0;
+    Py_buffer *databufs = NULL;
+    struct iovec *iovs = NULL;
+    sock_addr_t addrbuf;
+    static const struct msghdr msg_blank;
+    struct msghdr msg;
+    struct cmsginfo {
+        int level;
+        int type;
+        Py_buffer data;
+    } *cmsgs = NULL;
+    void *controlbuf = NULL;
+    size_t controllen, controllen_last;
+    ssize_t bytes_sent = -1;
+    int addrlen, timeout, flags = 0;
+    PyObject *data_arg, *cmsg_arg = NULL, *addr_arg = NULL, *data_fast = NULL,
+        *cmsg_fast = NULL, *retval = NULL;
+
+    if (!PyArg_ParseTuple(args, "O|OiO:sendmsg",
+                          &data_arg, &cmsg_arg, &flags, &addr_arg))
+        return NULL;
+
+    msg = msg_blank;    /* Set all members to 0 or NULL */
+
+    /* Parse destination address. */
+    if (addr_arg != NULL && addr_arg != Py_None) {
+        if (!getsockaddrarg(s, addr_arg, SAS2SA(&addrbuf), &addrlen))
+            goto finally;
+        msg.msg_name = &addrbuf;
+        msg.msg_namelen = addrlen;
+    }
+
+    /* Fill in an iovec for each message part, and save the Py_buffer
+       structs to release afterwards. */
+    if ((data_fast = PySequence_Fast(data_arg,
+                                     "sendmsg() argument 1 must be an "
+                                     "iterable")) == NULL)
+        goto finally;
+    ndataparts = PySequence_Fast_GET_SIZE(data_fast);
+    if (ndataparts > INT_MAX) {
+        PyErr_SetString(socket_error, "sendmsg() argument 1 is too long");
+        goto finally;
+    }
+    msg.msg_iovlen = ndataparts;
+    if (ndataparts > 0 &&
+        ((msg.msg_iov = iovs = PyMem_New(struct iovec, ndataparts)) == NULL ||
+         (databufs = PyMem_New(Py_buffer, ndataparts)) == NULL)) {
+        PyErr_NoMemory();
+        goto finally;
+    }
+    for (; ndatabufs < ndataparts; ndatabufs++) {
+        if (!PyArg_Parse(PySequence_Fast_GET_ITEM(data_fast, ndatabufs),
+                         "s*;sendmsg() argument 1 must be an iterable of "
+                         "buffer-compatible objects",
+                         &databufs[ndatabufs]))
+            goto finally;
+        iovs[ndatabufs].iov_base = databufs[ndatabufs].buf;
+        iovs[ndatabufs].iov_len = databufs[ndatabufs].len;
+    }
+
+    if (cmsg_arg == NULL)
+        ncmsgs = 0;
+    else {
+        if ((cmsg_fast = PySequence_Fast(cmsg_arg,
+                                         "sendmsg() argument 2 must be an "
+                                         "iterable")) == NULL)
+            goto finally;
+        ncmsgs = PySequence_Fast_GET_SIZE(cmsg_fast);
+    }
+
+#ifndef CMSG_SPACE
+    if (ncmsgs > 1) {
+        PyErr_SetString(socket_error,
+                        "sending multiple control messages is not supported "
+                        "on this system");
+        goto finally;
+    }
+#endif
+    /* Save level, type and Py_buffer for each control message,
+       and calculate total size. */
+    if (ncmsgs > 0 && (cmsgs = PyMem_New(struct cmsginfo, ncmsgs)) == NULL) {
+        PyErr_NoMemory();
+        goto finally;
+    }
+    controllen = controllen_last = 0;
+    while (ncmsgbufs < ncmsgs) {
+        size_t bufsize, space;
+
+        if (!PyArg_Parse(PySequence_Fast_GET_ITEM(cmsg_fast, ncmsgbufs),
+                         "(iis*):[sendmsg() ancillary data items]",
+                         &cmsgs[ncmsgbufs].level,
+                         &cmsgs[ncmsgbufs].type,
+                         &cmsgs[ncmsgbufs].data))
+            goto finally;
+        bufsize = cmsgs[ncmsgbufs++].data.len;
+
+#ifdef CMSG_SPACE
+        if (!get_CMSG_SPACE(bufsize, &space)) {
+#else
+        if (!get_CMSG_LEN(bufsize, &space)) {
+#endif
+            PyErr_SetString(socket_error, "ancillary data item too large");
+            goto finally;
+        }
+        controllen += space;
+        if (controllen > SOCKLEN_T_LIMIT || controllen < controllen_last) {
+            PyErr_SetString(socket_error, "too much ancillary data");
+            goto finally;
+        }
+        controllen_last = controllen;
+    }
+
+    /* Construct ancillary data block from control message info. */
+    if (ncmsgbufs > 0) {
+        struct cmsghdr *cmsgh = NULL;
+
+        if ((msg.msg_control = controlbuf =
+             PyMem_Malloc(controllen)) == NULL) {
+            PyErr_NoMemory();
+            goto finally;
+        }
+        msg.msg_controllen = controllen;
+
+        /* Need to zero out the buffer as a workaround for glibc's
+           CMSG_NXTHDR() implementation.  After getting the pointer to
+           the next header, it checks its (uninitialized) cmsg_len
+           member to see if the "message" fits in the buffer, and
+           returns NULL if it doesn't.  Zero-filling the buffer
+           ensures that that doesn't happen. */
+        memset(controlbuf, 0, controllen);
+
+        for (i = 0; i < ncmsgbufs; i++) {
+            size_t msg_len, data_len = cmsgs[i].data.len;
+            int enough_space = 0;
+
+            cmsgh = (i == 0) ? CMSG_FIRSTHDR(&msg) : CMSG_NXTHDR(&msg, cmsgh);
+            if (cmsgh == NULL) {
+                PyErr_Format(PyExc_RuntimeError,
+                             "unexpected NULL result from %s()",
+                             (i == 0) ? "CMSG_FIRSTHDR" : "CMSG_NXTHDR");
+                goto finally;
+            }
+            if (!get_CMSG_LEN(data_len, &msg_len)) {
+                PyErr_SetString(PyExc_RuntimeError,
+                                "item size out of range for CMSG_LEN()");
+                goto finally;
+            }
+            if (cmsg_min_space(&msg, cmsgh, msg_len)) {
+                size_t space;
+
+                cmsgh->cmsg_len = msg_len;
+                if (get_cmsg_data_space(&msg, cmsgh, &space))
+                    enough_space = (space >= data_len);
+            }
+            if (!enough_space) {
+                PyErr_SetString(PyExc_RuntimeError,
+                                "ancillary data does not fit in calculated "
+                                "space");
+                goto finally;
+            }
+            cmsgh->cmsg_level = cmsgs[i].level;
+            cmsgh->cmsg_type = cmsgs[i].type;
+            memcpy(CMSG_DATA(cmsgh), cmsgs[i].data.buf, data_len);
+        }
+    }
+
+    /* Make the system call. */
+    if (!IS_SELECTABLE(s)) {
+        select_error();
+        goto finally;
+    }
+
+    Py_BEGIN_ALLOW_THREADS;
+    timeout = internal_select(s, 1);
+    if (!timeout)
+        bytes_sent = sendmsg(s->sock_fd, &msg, flags);
+    Py_END_ALLOW_THREADS;
+
+    if (timeout == 1) {
+        PyErr_SetString(socket_timeout, "timed out");
+        goto finally;
+    }
+
+    if (bytes_sent < 0) {
+        s->errorhandler();
+        goto finally;
+    }
+    retval = PyInt_FromSsize_t(bytes_sent);
+
+finally:
+    PyMem_Free(controlbuf);
+    for (i = 0; i < ncmsgbufs; i++)
+        PyBuffer_Release(&cmsgs[i].data);
+    PyMem_Free(cmsgs);
+    Py_XDECREF(cmsg_fast);
+    for (i = 0; i < ndatabufs; i++)
+        PyBuffer_Release(&databufs[i]);
+    PyMem_Free(databufs);
+    PyMem_Free(iovs);
+    Py_XDECREF(data_fast);
+    return retval;
+}
+
+PyDoc_STRVAR(sendmsg_doc,
+"sendmsg(buffers[, ancdata[, flags[, address]]]) -> count\n\
+\n\
+Send normal and ancillary data to the socket, gathering the\n\
+non-ancillary data from a series of buffers and concatenating it into\n\
+a single message.  The buffers argument specifies the non-ancillary\n\
+data as an iterable of buffer-compatible objects (e.g. bytes objects).\n\
+The ancdata argument specifies the ancillary data (control messages)\n\
+as an iterable of zero or more tuples (cmsg_level, cmsg_type,\n\
+cmsg_data), where cmsg_level and cmsg_type are integers specifying the\n\
+protocol level and protocol-specific type respectively, and cmsg_data\n\
+is a buffer-compatible object holding the associated data.  The flags\n\
+argument defaults to 0 and has the same meaning as for send().  If\n\
+address is supplied and not None, it sets a destination address for\n\
+the message.  The return value is the number of bytes of non-ancillary\n\
+data sent.");
+#endif    /* CMSG_LEN */
+
+
 /* s.shutdown(how) method */
 
 static PyObject *
@@ -3019,6 +3699,14 @@ static PyMethodDef sock_methods[] = {
     {"sleeptaskw",        (PyCFunction)sock_sleeptaskw, METH_O,
                       sleeptaskw_doc},
 #endif
+#ifdef CMSG_LEN
+    {"recvmsg",           (PyCFunction)sock_recvmsg, METH_VARARGS,
+                      recvmsg_doc},
+    {"recvmsg_into",      (PyCFunction)sock_recvmsg_into, METH_VARARGS,
+                      recvmsg_into_doc,},
+    {"sendmsg",           (PyCFunction)sock_sendmsg, METH_VARARGS,
+                      sendmsg_doc},
+#endif
     {NULL,                      NULL}           /* sentinel */
 };
 
@@ -4287,6 +4975,68 @@ A value of None indicates that new socke
 When the socket module is first imported, the default is None.");
 
 
+#ifdef CMSG_LEN
+/* Python interface to CMSG_LEN(length). */
+
+static PyObject *
+socket_CMSG_LEN(PyObject *self, PyObject *args)
+{
+    Py_ssize_t length;
+    size_t result;
+
+    if (!PyArg_ParseTuple(args, "n:CMSG_LEN", &length))
+        return NULL;
+    if (length < 0 || !get_CMSG_LEN(length, &result)) {
+        PyErr_Format(PyExc_OverflowError, "CMSG_LEN() argument out of range");
+        return NULL;
+    }
+    return PyInt_FromSize_t(result);
+}
+
+PyDoc_STRVAR(CMSG_LEN_doc,
+"CMSG_LEN(length) -> control message length\n\
+\n\
+Return the total length, without trailing padding, of an ancillary\n\
+data item with associated data of the given length.  This value can\n\
+often be used as the buffer size for recvmsg() to receive a single\n\
+item of ancillary data, but RFC 3542 requires portable applications to\n\
+use CMSG_SPACE() and thus include space for padding, even when the\n\
+item will be the last in the buffer.  Raises OverflowError if length\n\
+is outside the permissible range of values.");
+
+
+#ifdef CMSG_SPACE
+/* Python interface to CMSG_SPACE(length). */
+
+static PyObject *
+socket_CMSG_SPACE(PyObject *self, PyObject *args)
+{
+    Py_ssize_t length;
+    size_t result;
+
+    if (!PyArg_ParseTuple(args, "n:CMSG_SPACE", &length))
+        return NULL;
+    if (length < 0 || !get_CMSG_SPACE(length, &result)) {
+        PyErr_SetString(PyExc_OverflowError,
+                        "CMSG_SPACE() argument out of range");
+        return NULL;
+    }
+    return PyInt_FromSize_t(result);
+}
+
+PyDoc_STRVAR(CMSG_SPACE_doc,
+"CMSG_SPACE(length) -> buffer size\n\
+\n\
+Return the buffer size needed for recvmsg() to receive an ancillary\n\
+data item with associated data of the given length, along with any\n\
+trailing padding.  The buffer space needed to receive multiple items\n\
+is the sum of the CMSG_SPACE() values for their associated data\n\
+lengths.  Raises OverflowError if length is outside the permissible\n\
+range of values.");
+#endif    /* CMSG_SPACE */
+#endif    /* CMSG_LEN */
+
+
 /* List of functions exported by this module. */
 
 static PyMethodDef socket_methods[] = {
@@ -4338,6 +5088,14 @@ static PyMethodDef socket_methods[] = {
      METH_NOARGS, getdefaulttimeout_doc},
     {"setdefaulttimeout",       socket_setdefaulttimeout,
      METH_O, setdefaulttimeout_doc},
+#ifdef CMSG_LEN
+    {"CMSG_LEN",                socket_CMSG_LEN,
+     METH_VARARGS, CMSG_LEN_doc},
+#ifdef CMSG_SPACE
+    {"CMSG_SPACE",              socket_CMSG_SPACE,
+     METH_VARARGS, CMSG_SPACE_doc},
+#endif
+#endif
     {NULL,                      NULL}            /* Sentinel */
 };
 
@@ -4836,6 +5594,15 @@ init_socket(void)
 #ifdef SO_SETFIB
     PyModule_AddIntConstant(m, "SO_SETFIB", SO_SETFIB);
 #endif
+#ifdef  SO_PASSCRED
+    PyModule_AddIntConstant(m, "SO_PASSCRED", SO_PASSCRED);
+#endif
+#ifdef  SO_PEERCRED
+    PyModule_AddIntConstant(m, "SO_PEERCRED", SO_PEERCRED);
+#endif
+#ifdef  LOCAL_PEERCRED
+    PyModule_AddIntConstant(m, "LOCAL_PEERCRED", LOCAL_PEERCRED);
+#endif
 
     /* Maximum number of connections for "listen" */
 #ifdef  SOMAXCONN
@@ -4844,6 +5611,17 @@ init_socket(void)
     PyModule_AddIntConstant(m, "SOMAXCONN", 5); /* Common value */
 #endif
 
+    /* Ancilliary message types */
+#ifdef  SCM_RIGHTS
+    PyModule_AddIntConstant(m, "SCM_RIGHTS", SCM_RIGHTS);
+#endif
+#ifdef  SCM_CREDENTIALS
+    PyModule_AddIntConstant(m, "SCM_CREDENTIALS", SCM_CREDENTIALS);
+#endif
+#ifdef  SCM_CREDS
+    PyModule_AddIntConstant(m, "SCM_CREDS", SCM_CREDS);
+#endif
+
     /* Flags for send, recv */
 #ifdef  MSG_OOB
     PyModule_AddIntConstant(m, "MSG_OOB", MSG_OOB);
@@ -4875,6 +5653,33 @@ init_socket(void)
 #ifdef  MSG_ETAG
     PyModule_AddIntConstant(m, "MSG_ETAG", MSG_ETAG);
 #endif
+#ifdef  MSG_NOSIGNAL
+    PyModule_AddIntConstant(m, "MSG_NOSIGNAL", MSG_NOSIGNAL);
+#endif
+#ifdef  MSG_NOTIFICATION
+    PyModule_AddIntConstant(m, "MSG_NOTIFICATION", MSG_NOTIFICATION);
+#endif
+#ifdef  MSG_CMSG_CLOEXEC
+    PyModule_AddIntConstant(m, "MSG_CMSG_CLOEXEC", MSG_CMSG_CLOEXEC);
+#endif
+#ifdef  MSG_ERRQUEUE
+    PyModule_AddIntConstant(m, "MSG_ERRQUEUE", MSG_ERRQUEUE);
+#endif
+#ifdef  MSG_CONFIRM
+    PyModule_AddIntConstant(m, "MSG_CONFIRM", MSG_CONFIRM);
+#endif
+#ifdef  MSG_MORE
+    PyModule_AddIntConstant(m, "MSG_MORE", MSG_MORE);
+#endif
+#ifdef  MSG_EOF
+    PyModule_AddIntConstant(m, "MSG_EOF", MSG_EOF);
+#endif
+#ifdef  MSG_BCAST
+    PyModule_AddIntConstant(m, "MSG_BCAST", MSG_BCAST);
+#endif
+#ifdef  MSG_MCAST
+    PyModule_AddIntConstant(m, "MSG_MCAST", MSG_MCAST);
+#endif
 
     /* Protocol level and numbers, usable for [gs]etsockopt */
 #ifdef  SOL_SOCKET
@@ -5014,6 +5819,9 @@ init_socket(void)
 #ifdef  IPPROTO_VRRP
     PyModule_AddIntConstant(m, "IPPROTO_VRRP", IPPROTO_VRRP);
 #endif
+#ifdef  IPPROTO_SCTP
+    PyModule_AddIntConstant(m, "IPPROTO_SCTP", IPPROTO_SCTP);
+#endif
 #ifdef  IPPROTO_BIP
     PyModule_AddIntConstant(m, "IPPROTO_BIP", IPPROTO_BIP);
 #endif

From report at bugs.python.org  Sun Jun  5 23:47:16 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 05 Jun 2011 21:47:16 +0000
Subject: [issue12268] file readline & readlines methods can lose data on EINTR
In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za>
Message-ID: <1307310436.05.0.660291301421.issue12268@psf.upfronthosting.co.za>


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

3.x has the same issue.  unittest & patch forthcoming that addresses that as well.

2.6 also has the issue but it is in security fix only mode so I won't backport to that.

----------
versions: +Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jun  6 00:05:16 2011
From: report at bugs.python.org (Roger Binns)
Date: Sun, 05 Jun 2011 22:05:16 +0000
Subject: [issue12265] revamp argument errors
In-Reply-To: <1307240443.69.0.736494632157.issue12265@psf.upfronthosting.co.za>
Message-ID: <1307311516.44.0.996244643412.issue12265@psf.upfronthosting.co.za>


Roger Binns <python at rogerbinns.com> added the comment:

Is there any reason it doesn't show the function 'prototype' which is by far the most the useful piece of information and is also a form of documentation (plus fairly hard to work out).  Convoluted technospeak is far harder to understand.  Compare:

TypeError: f() takes from 1 to 2 positional arguments but 0 were given

versus:

TypeError: f(a, b=2) takes from 1 to 2 positional arguments but 0 were given

----------
nosy: +rogerbinns

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

From report at bugs.python.org  Mon Jun  6 01:01:55 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 05 Jun 2011 23:01:55 +0000
Subject: [issue12265] revamp argument errors
In-Reply-To: <1307240443.69.0.736494632157.issue12265@psf.upfronthosting.co.za>
Message-ID: <1307314915.44.0.553863406662.issue12265@psf.upfronthosting.co.za>


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

-1 on adding the prototype (especially since I think it isn't always possible to do so).  In many cases it would make the message overlong, and the user can look up the prototype by looking at their source code or using pydoc or their IDE.  The error message should contain the information that isn't available by looking at the source code.

----------

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

From report at bugs.python.org  Mon Jun  6 01:35:26 2011
From: report at bugs.python.org (Brian May)
Date: Sun, 05 Jun 2011 23:35:26 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1307316926.36.0.827874152106.issue6560@psf.upfronthosting.co.za>


Brian May <brian at microcomaustralia.com.au> added the comment:

To address some of the comments above:

* Yes, the patch is large. However, most of this is in the tests. Only A relatively small part is in the code that implements the required functionality. I don't care much myself about the test cases, however would have assumed these would help get it into upstream.

(baikie-hwundram-v5-hg.diff)

 Doc/library/socket.rst  |  176 +++
 Lib/ssl.py              |   24 
 Lib/test/test_socket.py | 2120 ++++++++++++++++++++++++++++++++++++++++++++++++
 Lib/test/test_ssl.py    |   13 
 Modules/socketmodule.c  |  809 ++++++++++++++++++
 5 files changed, 3142 insertions(+)

* raw sockets are inappropriate for using UDP TPROXY support. I don't want to bypass the kernel code and have to pass headers etc myself, I just want to get the destination address so I know where the packet was original destined for. recvmsg() is the correct solution.

* Thanks for the 2.x patch. Will try that out now.

----------

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

From report at bugs.python.org  Mon Jun  6 02:18:58 2011
From: report at bugs.python.org (py.user)
Date: Mon, 06 Jun 2011 00:18:58 +0000
Subject: [issue12266] str.capitalize contradicts
In-Reply-To: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>
Message-ID: <1307319538.49.0.391665921325.issue12266@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

in http://bugs.python.org/issue12204
Marc-Andre Lemburg wrote:
I suggest to close this ticket as invalid or to add a note
to the documentation explaining how the mapping is applied
(and when not).

this problem is another
str.capitalize makes the first character big, but it doesn't make the rest small
clearing documentation is not enough

lowering works
>>> '\u1ffc'
'?'
>>> '\u1ffc'.lower()
'?'
>>>

----------

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

From report at bugs.python.org  Mon Jun  6 02:21:55 2011
From: report at bugs.python.org (py.user)
Date: Mon, 06 Jun 2011 00:21:55 +0000
Subject: [issue12266] str.capitalize contradicts
In-Reply-To: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>
Message-ID: <1307319715.87.0.278294374778.issue12266@psf.upfronthosting.co.za>


Changes by py.user <port139 at yandex.ru>:


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

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

From report at bugs.python.org  Mon Jun  6 02:22:44 2011
From: report at bugs.python.org (py.user)
Date: Mon, 06 Jun 2011 00:22:44 +0000
Subject: [issue12266] str.capitalize contradicts oneself
In-Reply-To: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>
Message-ID: <1307319764.47.0.743026138107.issue12266@psf.upfronthosting.co.za>


Changes by py.user <port139 at yandex.ru>:


----------
title: str.capitalize contradicts -> str.capitalize contradicts oneself

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

From report at bugs.python.org  Mon Jun  6 02:32:03 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 06 Jun 2011 00:32:03 +0000
Subject: [issue12019] Dead or buggy code in importlib.test.__main__
In-Reply-To: <1304698107.84.0.876175210451.issue12019@psf.upfronthosting.co.za>
Message-ID: <1307320323.26.0.422175848221.issue12019@psf.upfronthosting.co.za>


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

Yeah, it's dead code so go ahead and rip it out.

----------
assignee:  -> eric.araujo

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

From report at bugs.python.org  Mon Jun  6 02:36:31 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 06 Jun 2011 00:36:31 +0000
Subject: [issue12268] file readline,
	readlines & readall methods can lose data on EINTR
In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za>
Message-ID: <1307320591.3.0.633454245823.issue12268@psf.upfronthosting.co.za>


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

.readall() and the equivalent unbounded .read() also have this problem.

----------
title: file readline & readlines methods can lose data on EINTR -> file readline, readlines & readall methods can lose data on EINTR

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

From report at bugs.python.org  Mon Jun  6 02:42:12 2011
From: report at bugs.python.org (Roger Binns)
Date: Mon, 06 Jun 2011 00:42:12 +0000
Subject: [issue12265] revamp argument errors
In-Reply-To: <1307240443.69.0.736494632157.issue12265@psf.upfronthosting.co.za>
Message-ID: <1307320932.31.0.0158971775599.issue12265@psf.upfronthosting.co.za>


Roger Binns <python at rogerbinns.com> added the comment:

Obviously the prototype can't be provided when it isn't known.  But the pseudo-English text is trying to describe the prototype and is far less clear than the actual prototype.  ie the developer communicated the prototype to Python in Python syntax, why not have Python do the same rather than use a different and very unfamiliar language.  (Try using the Python documentation to work out what the word 'positional' means.)

As for looking it up in the source code, that is one of the harder things for newbies to do, and certainly very difficult for a lot of people.  How would they know where the standard library source is on their system?  Heck I don't even know where the source is for third party packages on my Ubuntu system as the last I looked they used convoluted sequences of version numbers, symbolic links and who knows what else.  The popularity of eggs makes it even harder to look up.

----------

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

From report at bugs.python.org  Mon Jun  6 03:21:24 2011
From: report at bugs.python.org (Ryan Hollis)
Date: Mon, 06 Jun 2011 01:21:24 +0000
Subject: [issue12269] Crashes on start
In-Reply-To: <1307323284.04.0.790241806386.issue12269@psf.upfronthosting.co.za>
Message-ID: <1307323284.04.0.790241806386.issue12269@psf.upfronthosting.co.za>


New submission from Ryan Hollis <theryanhollis at gmail.com>:

Mac OSX Snow Leopard, Python 2.7, 
The moment I paste anything into the editor window, it crashes. Also IDLE crashes within a minute or two of opening, wether or not I actually do anything with it after opening it.
uninstalled and reinstalled, didnt help

----------
messages: 137724
nosy: Ryan.Hollis
priority: normal
severity: normal
status: open
title: Crashes on start

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

From report at bugs.python.org  Mon Jun  6 03:38:38 2011
From: report at bugs.python.org (John O'Connor)
Date: Mon, 06 Jun 2011 01:38:38 +0000
Subject: [issue12268] file readline,
	readlines & readall methods can lose data on EINTR
In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za>
Message-ID: <1307324318.09.0.0675248020794.issue12268@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
nosy: +jcon

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

From report at bugs.python.org  Mon Jun  6 03:53:34 2011
From: report at bugs.python.org (Ori Livneh)
Date: Mon, 06 Jun 2011 01:53:34 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1307325214.92.0.615849724737.issue11197@psf.upfronthosting.co.za>


Changes by Ori Livneh <ori.livneh at gmail.com>:


----------
nosy: +Ori.Livneh

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

From report at bugs.python.org  Mon Jun  6 04:06:49 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Jun 2011 02:06:49 +0000
Subject: [issue12265] revamp argument errors
In-Reply-To: <1307240443.69.0.736494632157.issue12265@psf.upfronthosting.co.za>
Message-ID: <1307326009.46.0.839747184223.issue12265@psf.upfronthosting.co.za>


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

That's why I said "their own source or pydoc...".

The language of the error message is trying to describe the error as the interpreter knows about it at the time the error is generated.  That has a strong relationship to the prototype, but the two things are not the same.

IMO the added complexity of finding and displaying the prototype is not worth it.  But it is Benjamin who was willing to tackle trying to fix the current problems with the error messages, so I'm happy to leave that decision up to him.

----------

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

From report at bugs.python.org  Mon Jun  6 04:11:15 2011
From: report at bugs.python.org (Ori Livneh)
Date: Mon, 06 Jun 2011 02:11:15 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1307326275.79.0.301303623953.issue11197@psf.upfronthosting.co.za>


Ori Livneh <ori.livneh at gmail.com> added the comment:

I've attached my proposal for a fix. It's my first, so apologies if I've made a mistake somewhere. Senthil Kumaran, to whom the bug is currently assigned, kindly agreed to let me take a stab at it (thanks!).

The approach I took was to normalize the path by replacing each of os.sep and os.altsep with slashes if (a) these characters are present in the path component and (b) the operating system is such that os.sep or os.altsep != '/'. (Currently, os.altsep is either None or '/' on all systems, but it seemed like a good idea to check anyway.)

Requesting a relative path which, when translated, would point above the current working directory (e.g. http://localhost:8000/../) causes the server to return a 400 error, which is just how Apache responds to such requests.

Internal calls to translate_path with such malformed paths cause translate_path to raise an IndexError, which is consistent with how _url_collapse_path_split (used by CGIRequestHandler) handles them.

----------
keywords: +patch
Added file: http://bugs.python.org/file22260/translate_path.patch

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

From report at bugs.python.org  Mon Jun  6 04:42:10 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Jun 2011 02:42:10 +0000
Subject: [issue12234] unittest2 could enable regex debugging for more
	information
In-Reply-To: <1306933404.89.0.697079292496.issue12234@psf.upfronthosting.co.za>
Message-ID: <1307328130.89.0.849584603662.issue12234@psf.upfronthosting.co.za>


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

I'm closing this as invalid.  If someone wants to work on this feature, they'll first have to add debugging to re....

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

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

From report at bugs.python.org  Mon Jun  6 05:05:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 06 Jun 2011 03:05:10 +0000
Subject: [issue12265] revamp argument errors
In-Reply-To: <1307240443.69.0.736494632157.issue12265@psf.upfronthosting.co.za>
Message-ID: <E1QTQ7p-0006Oe-1t@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 44d46d74ef4f by Benjamin Peterson in branch 'default':
greatly improve argument parsing error messages (closes #12265)
http://hg.python.org/cpython/rev/44d46d74ef4f

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Jun  6 05:53:25 2011
From: report at bugs.python.org (Amar Takhar)
Date: Mon, 06 Jun 2011 03:53:25 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1307332405.24.0.0245629195402.issue10694@psf.upfronthosting.co.za>


Amar Takhar <verm at aegisub.org> added the comment:

This patch fixed every BadZipfile exception (~300) I got while testing over 50,000 zipfiles. (Applied to 2.7)

It would be nice to see this bug resolved.

----------
nosy: +verm

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

From report at bugs.python.org  Mon Jun  6 06:07:18 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 06 Jun 2011 04:07:18 +0000
Subject: [issue12268] file readline,
	readlines & readall methods can lose data on EINTR
In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za>
Message-ID: <1307333238.2.0.153628957072.issue12268@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file22261/test_fileio_readers_3.2-gps01.diff

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

From report at bugs.python.org  Mon Jun  6 07:44:37 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 06 Jun 2011 05:44:37 +0000
Subject: [issue12269] IDLE 2.7 hangs on Mac OS X 10.6
In-Reply-To: <1307323284.04.0.790241806386.issue12269@psf.upfronthosting.co.za>
Message-ID: <1307339077.36.0.771156960804.issue12269@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Assuming you are using the "Mac OS X 64-bit/32-bit x86-64/i386 Installer (2.7.1) for Mac OS X 10.6", note that the download page was updated sometime ago to include the following warning: "[You may not be able to run IDLE or use Tkinter with this installer] and refers you to: 

    http://www.python.org/download/mac/tcltk/

As noted there, there are problems with using IDLE with that installer; the recommended solutions there are to either install the most recent ActiveState Tcl/Tk 8.5.9 and a newer version of the 2.7.x 64-bit/32-bit installer (2.7.2rc1 is currently available, the final 2.7.2 version is expected to be available later in June).

   http://python.org/download/releases/2.7.2/

Or switch to the 32-bit-only 2.7.1 installer for OS X which does not link with the problematic Apple-supplied Tcl/Tk 8.5.

If this does not solve the problems you are seeing, please re-open and supply more information about exactly which Python you are using and the errant behavior.

----------
assignee:  -> ned.deily
components: +IDLE, Macintosh
nosy: +ned.deily
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
title: Crashes on start -> IDLE 2.7 hangs on Mac OS X 10.6
versions: +Python 2.7

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

From report at bugs.python.org  Mon Jun  6 09:35:10 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 06 Jun 2011 07:35:10 +0000
Subject: [issue12268] file readline,
	readlines & readall methods can lose data on EINTR
In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za>
Message-ID: <1307345710.07.0.787736307829.issue12268@psf.upfronthosting.co.za>


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

I haven't looked beyond the reading methods it is possible that some of the write implementations have a similar issue.  Patch gps02 for 3.2 attached.

I'll use that as the basis for a stand alone test_file_eintr.py targeted at 2.7.

----------
Added file: http://bugs.python.org/file22262/test_and_fix_readers_3.2-gps02.diff

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

From report at bugs.python.org  Mon Jun  6 09:35:56 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 06 Jun 2011 07:35:56 +0000
Subject: [issue12268] file readline,
	readlines & readall methods can lose data on EINTR
In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za>
Message-ID: <1307345756.37.0.109052831622.issue12268@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file22261/test_fileio_readers_3.2-gps01.diff

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

From report at bugs.python.org  Mon Jun  6 10:04:15 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 06 Jun 2011 08:04:15 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1307198026.95.0.503396895817.issue12226@psf.upfronthosting.co.za>
Message-ID: <BANLkTin7jnHg=qAfbZMynmGyTc51tFti=w@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Sat, Jun 4, 2011 at 5:33 PM, ?ric Araujo <report at bugs.python.org> wrote:>
>> I think there should be a warning that the connection is
>> unauthenticated (i.e. not secure). Users tend to be upset if they see
>> 'https' and later find out that no certificates were verified.
>
> Thanks Stephan, that was on my mind but I forgot it. ?I?m -1 on using https if no validation is performed.

It will be more professional if you could also explain why. Thanks.

>> I believe that's a very personal judgement.
> Not really; it?s an explanation of our release rules, exposed by one of the older developers.

Release rules should be clear enough not to require explanation.

>> For me exposing core Python development accounts is a fundamental
>> flaw.

> What is a core Python development account?

'core' is not the best word here, so it needs an explanation. Any
account on PyPI that uploads packages used for in enterprise
deployment schemes imposes a danger. Potential target are identified
using 'popularity package/developer activity' rating to reduce the
risk. These are the primary targets for an attack, which I called
'core'. 'primary' would be a better name probably.

----------

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

From report at bugs.python.org  Mon Jun  6 13:23:39 2011
From: report at bugs.python.org (Xuanji Li)
Date: Mon, 06 Jun 2011 11:23:39 +0000
Subject: [issue12170] Bytes.index() and bytes.count() should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1307359419.39.0.0872291208094.issue12170@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/issue12170>
_______________________________________

From report at bugs.python.org  Mon Jun  6 13:27:14 2011
From: report at bugs.python.org (Xuanji Li)
Date: Mon, 06 Jun 2011 11:27:14 +0000
Subject: [issue10376] ZipFile unzip is unbuffered
In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za>
Message-ID: <1307359634.79.0.405081486481.issue10376@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/issue10376>
_______________________________________

From report at bugs.python.org  Mon Jun  6 14:27:22 2011
From: report at bugs.python.org (Aron Griffis)
Date: Mon, 06 Jun 2011 12:27:22 +0000
Subject: [issue3566] httplib persistent connections violate MUST in RFC2616
	sec 8.1.4.
In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>
Message-ID: <1307363242.46.0.602097990907.issue3566@psf.upfronthosting.co.za>


Changes by Aron Griffis <agriffis at n01se.net>:


----------
nosy: +agriffis

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

From report at bugs.python.org  Mon Jun  6 14:39:36 2011
From: report at bugs.python.org (AJ)
Date: Mon, 06 Jun 2011 12:39:36 +0000
Subject: [issue12270] Please update copyright notice on bugs.python.org to
	2011?
In-Reply-To: <1307363976.46.0.271724465254.issue12270@psf.upfronthosting.co.za>
Message-ID: <1307363976.46.0.271724465254.issue12270@psf.upfronthosting.co.za>


New submission from AJ <brandmyself at gmail.com>:

We are almost in mid-year. :)

http://bugs.python.org/ has a copyright notice "1990-2010". Please update it to include 2011.

----------
components: None
messages: 137736
nosy: brandmyself
priority: normal
severity: normal
status: open
title: Please update copyright notice on bugs.python.org to 2011?

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

From report at bugs.python.org  Mon Jun  6 15:01:38 2011
From: report at bugs.python.org (Vincent)
Date: Mon, 06 Jun 2011 13:01:38 +0000
Subject: [issue12271] Python 2.7.x on IA64 running SLES 11 SP1
In-Reply-To: <1307365298.12.0.602165301483.issue12271@psf.upfronthosting.co.za>
Message-ID: <1307365298.12.0.602165301483.issue12271@psf.upfronthosting.co.za>


New submission from Vincent <v.claudic at free.fr>:

Hello everybody,

With the same build/compile command, I'm able to have "my" runing python version (2.6.x or 2.7.x) on IA64 server runing SLES 10 SP2/SP3,not on IA64 server runing SLES 11 SP1. I've try with 2.7, 2.7.1 and 2.7.2rc1 version without success.

On both configuration types, I've installed all the available libraries, but on SLES 11 SP1, the make resulting message is the following (the complete building messages are in the joined gzip text file):

------------------
...
Python build finished, but the necessary bits to build these modules were not found:
_bsddb             _sqlite3           _ssl            
_tkinter           bsddb185           bz2             
dl                 imageop            readline        
sunaudiodev        zlib                               
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_curses_panel                                         

running build_scripts
------------------

Any advice will be welcome.

Thanks a lot for your attention and your process.

All the best,

Vincent

----------
components: Build
files: Building_error_SLES11SP1_ia64.txt.gz
messages: 137737
nosy: v.claudic at free.fr
priority: normal
severity: normal
status: open
title: Python 2.7.x on IA64 running SLES 11 SP1
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file22263/Building_error_SLES11SP1_ia64.txt.gz

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

From report at bugs.python.org  Mon Jun  6 15:46:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 06 Jun 2011 13:46:40 +0000
Subject: [issue12270] Please update copyright notice on bugs.python.org to
	2011?
In-Reply-To: <1307363976.46.0.271724465254.issue12270@psf.upfronthosting.co.za>
Message-ID: <1307368000.55.0.79691949485.issue12270@psf.upfronthosting.co.za>


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


----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti

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

From report at bugs.python.org  Mon Jun  6 16:00:08 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 06 Jun 2011 14:00:08 +0000
Subject: [issue12270] Please update copyright notice on bugs.python.org to
	2011?
In-Reply-To: <1307363976.46.0.271724465254.issue12270@psf.upfronthosting.co.za>
Message-ID: <1307368808.79.0.0843383728157.issue12270@psf.upfronthosting.co.za>


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

Done in r88853, thanks for the report!

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

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

From report at bugs.python.org  Mon Jun  6 16:42:25 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 06 Jun 2011 14:42:25 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1307272971.79.0.274030994244.issue12021@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=WBfDjetjObbNK7X_4+9=hbBPYpg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

>> That's because of the _PyIO_ConvertSsize_t converter, which silently
>> converts None to -1.
>> There's probably a good reason for doing this in the _io module
>
> I'm not sure about the original reason, but I find None as the default "omitted" value prettier than -1 myself, so I think it's a good thing :)
>

If being pretty is the only reason for this choice, then I think that
documenting the method as

method:: read([n])

is simpler and cleaner .

But you've got much more experience than me, so I won't argue any further :-)

> Can I use _PyIO_ConvertSsize_t? Or should I duplicate its
> functionality in mmapmodule.c?

I let Antoine answer that.

----------

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

From report at bugs.python.org  Mon Jun  6 16:56:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Jun 2011 14:56:06 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <BANLkTi=WBfDjetjObbNK7X_4+9=hbBPYpg@mail.gmail.com>
Message-ID: <1307372162.3506.5.camel@localhost.localdomain>


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

> If being pretty is the only reason for this choice, then I think that
> documenting the method as
> 
> method:: read([n])
> 
> is simpler and cleaner .
> 
> But you've got much more experience than me, so I won't argue any further :-)

There are contexts where it is easier to give the default argument than
call the method without argument, though, and that's where I find None
more intuitive than -1 :) Arguably it's not very important, though.

> > Can I use _PyIO_ConvertSsize_t? Or should I duplicate its
> > functionality in mmapmodule.c?
> 
> I let Antoine answer that.

I'm not sure. This would require including iomodule.h, which is supposed
to be private to the _io module. I think duplicating it is fine, since
the code is probably simple anyway (I'm too lazy to take a look right
now :-)).

----------

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

From report at bugs.python.org  Mon Jun  6 17:09:15 2011
From: report at bugs.python.org (Niels Heinen)
Date: Mon, 06 Jun 2011 15:09:15 +0000
Subject: [issue12238] Readline module loading in interactive mode
In-Reply-To: <1307015860.03.0.129842780518.issue12238@psf.upfronthosting.co.za>
Message-ID: <1307372955.69.0.766886823574.issue12238@psf.upfronthosting.co.za>


Niels Heinen <niels at heinen.ws> added the comment:

Hi Eric, David,

This means that you cannot type "python" and press <enter> in any shared directory without the risk of a malicious readlinemodule.so being imported and executed.  

I think this is different from a scenario where someone explicitly runs a script or imports a module in interactive mode where it is also reasonable that such a person understands the importing mechanism.

Thanks for the quick responses btw!

Niels

----------

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

From report at bugs.python.org  Mon Jun  6 17:13:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 06 Jun 2011 15:13:47 +0000
Subject: [issue12218] Removing wsgiref.egg-info
In-Reply-To: <1306774248.3.0.608189461621.issue12218@psf.upfronthosting.co.za>
Message-ID: <E1QTbUv-0000yP-PF@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset cc28bc86d474 by ?ric Araujo in branch 'default':
Remove wsgiref.egg-info from msi.py (follow-up to d615eb7bce33, #12218)
http://hg.python.org/cpython/rev/cc28bc86d474

----------

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

From report at bugs.python.org  Mon Jun  6 17:28:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Jun 2011 15:28:12 +0000
Subject: [issue12019] Dead or buggy code in importlib.test.__main__
In-Reply-To: <1304698107.84.0.876175210451.issue12019@psf.upfronthosting.co.za>
Message-ID: <1307374092.37.0.28570973767.issue12019@psf.upfronthosting.co.za>


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

Is this minor cleanup, non-bugfix okay for 3.2?

----------

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

From report at bugs.python.org  Mon Jun  6 17:33:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Jun 2011 15:33:46 +0000
Subject: [issue10884] pkgutil EggInfoDistribution requirements for .egg-info
	metadata
In-Reply-To: <1294721787.13.0.963133670506.issue10884@psf.upfronthosting.co.za>
Message-ID: <1307374426.06.0.858520577361.issue10884@psf.upfronthosting.co.za>


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

Can you check if this is covered in test_database?

----------

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

From report at bugs.python.org  Mon Jun  6 17:50:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Jun 2011 15:50:57 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1307375457.31.0.560375797852.issue12226@psf.upfronthosting.co.za>


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

>> Thanks Stephan, that was on my mind but I forgot it.  I?m -1 on
>> using https if no validation is performed.
> It will be more professional if you could also explain why.

If you make an HTTPS connection without checking the certificate, what security does it add?

> > Not really; it?s an explanation of our release rules, exposed by
>> one of the older developers.
> Release rules should be clear enough not to require explanation.

Explanations make them clear.

> Any account on PyPI that uploads packages used for in enterprise
> deployment schemes imposes a danger.

Sidenote: I don?t want to give less security to non-enterprise users.

Anyway, I understand your point now: insecure upload and download are vulnerable to MITM attacks, and encouraging HTTPS use (through default value + docs) would help against that.  I am supportive of a patch, but it doesn?t mean the release process should not be followed.  See also #11357 and #8561 about download security.

----------

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

From report at bugs.python.org  Mon Jun  6 17:57:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Jun 2011 15:57:05 +0000
Subject: [issue12246] Warn when trying to install third-party module from an
	uninstalled checkout
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307375825.94.0.858813484602.issue12246@psf.upfronthosting.co.za>


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

Thanks.  What about using sysconfig.is_python_build in your patch?

----------
assignee: tarek -> eric.araujo
title: create installation path if it's non-existent -> Warn when trying to install third-party module from an uninstalled checkout

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

From report at bugs.python.org  Mon Jun  6 18:01:10 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 06 Jun 2011 16:01:10 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1307375457.31.0.560375797852.issue12226@psf.upfronthosting.co.za>
Message-ID: <BANLkTinrukYChMNcUJKoRpm0DevJMGm-TQ@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

On Mon, Jun 6, 2011 at 11:50 AM, ?ric Araujo <report at bugs.python.org> wrote:
> If you make an HTTPS connection without checking the certificate, what security does it add?

I'm in favor of cert checking, myself.

----------

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

From report at bugs.python.org  Mon Jun  6 18:11:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Jun 2011 16:11:17 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1307376677.42.0.827207017091.issue7511@psf.upfronthosting.co.za>


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

Thorsten Behrens said:
> You are right, this is not a bug in Python. The diff provides a
> workaround for a limitation in VC++ 2008 Express. This diff is a
> piece of user service.

ipatrol added:
> Purity shmurity. The point of distutils is largely to present a
> unified and simple interface. 'python setup.py install' should be all
> a user has to do on any platform. Unless you can come up with a
> better idea, MSVC is really the only big compiler on Windows.

The feature freeze is distutils is not a conspiracy plotted by developers loving purity; it is a necessity caused by hard pragmatism.  Tarek would have loved to continue improving distutils instead of forking distutils2, but he could not because third-party code relying on bugs and workarounds was broken.  We have to be cautious, and it has nothing to do with purity.  Believe me, the freeze, fork and merge was not something fun for distutils developers, but we had to do it precisely for our users.

While I agree that in an ideal world, ?'python setup.py install' should be all a user has to do on any platform?, it cannot be done in distutils.  Like Martin said:
> if you want to use SDK tools, you are supposed to set
> DISTUTILS_USE_SDK, after opening the respective build environment

For distutils2/packaging however, we can work on improving the compiler system, so that ?pysetup run install? is all a user had to do on any platform.  See #12257 for that.

----------

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

From report at bugs.python.org  Mon Jun  6 18:12:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Jun 2011 16:12:18 +0000
Subject: [issue9302] distutils API Reference: setup() and Extension
	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1307376738.29.0.108601171179.issue9302@psf.upfronthosting.co.za>


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


----------
status: open -> pending

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

From report at bugs.python.org  Mon Jun  6 18:13:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Jun 2011 16:13:10 +0000
Subject: [issue12222] All pysetup commands should respect exit codes
In-Reply-To: <1306833373.02.0.231767797102.issue12222@psf.upfronthosting.co.za>
Message-ID: <1307376790.34.0.230180444713.issue12222@psf.upfronthosting.co.za>


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


----------
dependencies: +pysetup --search should return non-zero when a dist is not installed and print a message stating the fact.

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

From report at bugs.python.org  Mon Jun  6 18:16:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Jun 2011 16:16:03 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1307376963.88.0.103513325507.issue12242@psf.upfronthosting.co.za>


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

What would the value be for non-C Python implementations?

If the need for compiler-specific options is very common, we could consider either improving the compiler system or implement this request; if it?s not common, letting people use hooks would be enough.

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

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

From report at bugs.python.org  Mon Jun  6 18:23:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Jun 2011 16:23:06 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1307377386.02.0.651427218226.issue8668@psf.upfronthosting.co.za>


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


----------
assignee: tarek -> eric.araujo
keywords: +gsoc
title: add a 'develop' command -> Packaging: add a 'develop' command
versions: +Python 3.3 -3rd party

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

From report at bugs.python.org  Mon Jun  6 18:36:45 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 06 Jun 2011 16:36:45 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1307378205.19.0.285808984395.issue7511@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Hmm, in http://bugs.python.org/issue7511#msg106420 Tarek appeared to
be supportive of the patch.


Re DISTUTILS_USE_SDK:

I don't think many users are aware of this variable. Also, it is not
needed at all; it is sufficient to execute vcvars64.bat manually
before running setup.py.

----------

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

From report at bugs.python.org  Mon Jun  6 18:49:43 2011
From: report at bugs.python.org (Erik Bray)
Date: Mon, 06 Jun 2011 16:49:43 +0000
Subject: [issue12240] Allow multiple setup_hooks
In-Reply-To: <1307026779.27.0.653754848212.issue12240@psf.upfronthosting.co.za>
Message-ID: <1307378983.99.0.569491417567.issue12240@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

Adds support for multiple setup_hooks and updates the docs.

For now I left the option name as "setup_hook", though it might make sense to rename it to "setup_hooks" for consistency's sake.

----------
keywords: +patch
Added file: http://bugs.python.org/file22264/python_issue12240.patch

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

From report at bugs.python.org  Mon Jun  6 18:58:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Jun 2011 16:58:42 +0000
Subject: [issue12238] Readline module loading in interactive mode
In-Reply-To: <1307015860.03.0.129842780518.issue12238@psf.upfronthosting.co.za>
Message-ID: <1307379522.05.0.0112212275702.issue12238@psf.upfronthosting.co.za>


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

I've done a little poking around, and it looks like you are correct and I'm wrong. It appears that readline.so is or should be a special case.  I've added some people to nosy to see what they think.

Specifically, it appears that if I put a file that should shadow a library module that is imported at python startup time (eg: os.py) into my current working directory I still get the os.py from the appropriate lib directory, even though '' is first in my sys.path.  This is not how I thought it worked, but it is my observation.  I tested this on 2.6.6, 2.7.1 and 3.3 tip.

----------
nosy: +brett.cannon, haypo, pitrou
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jun  6 18:58:49 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 06 Jun 2011 16:58:49 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1307379529.99.0.635138634993.issue12196@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Hmm, thinking about it, I don't see any reason to make the flags argument optional.
Here's a patch changing that (also, pipe2 is now declared as METH_O instead of METH_VARARGS).

----------
Added file: http://bugs.python.org/file22265/pipe2_arg.diff

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

From report at bugs.python.org  Mon Jun  6 19:03:42 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 06 Jun 2011 17:03:42 +0000
Subject: [issue12271] Python 2.7.x on IA64 running SLES 11 SP1
In-Reply-To: <1307365298.12.0.602165301483.issue12271@psf.upfronthosting.co.za>
Message-ID: <1307379822.02.0.860440914127.issue12271@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

panel.h is not found. You'll need to install the package that
provides libpanel together with the header files:

error: panel.h: No such file or directory


This does not look like a Python bug, so I'll set the issue to
'pending'. You can still respond to the issue if you think otherwise.

----------
nosy: +skrah
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> pending

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

From report at bugs.python.org  Mon Jun  6 19:12:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Jun 2011 17:12:05 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1307379529.99.0.635138634993.issue12196@psf.upfronthosting.co.za>
Message-ID: <1307380322.3506.8.camel@localhost.localdomain>


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

> Hmm, thinking about it, I don't see any reason to make the flags argument optional.
> Here's a patch changing that (also, pipe2 is now declared as METH_O instead of METH_VARARGS).

Looks good to me.

----------

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

From report at bugs.python.org  Mon Jun  6 19:13:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Jun 2011 17:13:28 +0000
Subject: [issue11893] Obsolete SSLFakeFile in smtplib?
In-Reply-To: <1306611575.17.0.225268591838.issue11893@psf.upfronthosting.co.za>
Message-ID: <1307380402.3506.9.camel@localhost.localdomain>


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

> Note that I didn't test LMTP. Should I or is it obvious enough that the change is ok?

Thank you for the patch! I think it's ok. I'll give it a try and commit
if everything is alright.

----------

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

From report at bugs.python.org  Mon Jun  6 19:18:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 06 Jun 2011 17:18:03 +0000
Subject: [issue11893] Obsolete SSLFakeFile in smtplib?
In-Reply-To: <1303332884.98.0.410323888418.issue11893@psf.upfronthosting.co.za>
Message-ID: <E1QTdRC-0003ku-1e@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b68390b6dbfd by Antoine Pitrou in branch 'default':
Issue #11893: Remove obsolete internal wrapper class `SSLFakeFile` in the smtplib module.
http://hg.python.org/cpython/rev/b68390b6dbfd

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

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

From report at bugs.python.org  Mon Jun  6 19:19:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Jun 2011 17:19:10 +0000
Subject: [issue11893] Obsolete SSLFakeFile in smtplib?
In-Reply-To: <1303332884.98.0.410323888418.issue11893@psf.upfronthosting.co.za>
Message-ID: <1307380750.37.0.921097630273.issue11893@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jun  6 19:36:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 06 Jun 2011 17:36:07 +0000
Subject: [issue12040] Expose a Process.sentinel property (and fix polling loop
	in Process.join())
In-Reply-To: <1304966363.67.0.392142624447.issue12040@psf.upfronthosting.co.za>
Message-ID: <E1QTdig-0005F5-Ey@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 568a3ba088e4 by Antoine Pitrou in branch 'default':
Issue #12040: Expose a new attribute `sentinel` on instances of
http://hg.python.org/cpython/rev/568a3ba088e4

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

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

From report at bugs.python.org  Mon Jun  6 19:39:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Jun 2011 17:39:01 +0000
Subject: [issue12040] Expose a Process.sentinel property (and fix polling loop
	in Process.join())
In-Reply-To: <1304966363.67.0.392142624447.issue12040@psf.upfronthosting.co.za>
Message-ID: <1307381941.62.0.0125299494342.issue12040@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/issue12040>
_______________________________________

From report at bugs.python.org  Mon Jun  6 19:44:03 2011
From: report at bugs.python.org (Thanh Ly)
Date: Mon, 06 Jun 2011 17:44:03 +0000
Subject: [issue12232] embedded python import cmath
In-Reply-To: <1307232613.9.0.708738783793.issue12232@psf.upfronthosting.co.za>
Message-ID: <5E2D842CE82142D48786F8D932687BAE@ThanhPC>


Thanh Ly <thanh.l at ntlworld.com> added the comment:

Hi Terry

With BB 6 I import python26.dll and embed and extend Python in the same 
project (sent) fairly successfully. I converted the DLL to a BB format lib 
file and manage to extend Python successfully but could not link when trying 
to embed Python with the Lib file.

I would like to try with 2.7 and 3.1 however, I'm hard against it, time wise 
and not sure when I can verify the issue.

I did manage to try with 2.4 (as lib file was readily available for BB) and 
it worked.

Thank you for your advice and recommendations.

Thanh.

----------

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

From report at bugs.python.org  Mon Jun  6 19:44:11 2011
From: report at bugs.python.org (Alexander Myodov)
Date: Mon, 06 Jun 2011 17:44:11 +0000
Subject: [issue9099] multiprocessing/win32: WindowsError: [Error 0] Success on
	Pipe()
In-Reply-To: <1277729700.77.0.590017326086.issue9099@psf.upfronthosting.co.za>
Message-ID: <1307382251.59.0.956969242102.issue9099@psf.upfronthosting.co.za>


Alexander Myodov <amyodov at gmail.com> added the comment:

Sorry for being a little bit slow to respond...
No I was not able to come up with a testcase that could generate this problem in a reproducible way on any Windows box I had. This problem sometimes occured on various OS versions, being probably a Windows oof configuration problem rather than the problem of the Python code itself. Nevertheless, changing it as I described above didn't cause any adverse side effects, at least for me.

----------

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

From report at bugs.python.org  Mon Jun  6 19:50:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 06 Jun 2011 17:50:02 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <E1QTdw8-0006EX-MM@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ba975c7c33d3 by Charles-Fran?ois Natali in branch 'default':
Issue #12196: Make os.pipe2() flags argument mandatory.
http://hg.python.org/cpython/rev/ba975c7c33d3

----------

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

From report at bugs.python.org  Mon Jun  6 20:24:38 2011
From: report at bugs.python.org (Vincent)
Date: Mon, 06 Jun 2011 18:24:38 +0000
Subject: [issue12271] Python 2.7.x on IA64 running SLES 11 SP1
In-Reply-To: <1307365298.12.0.602165301483.issue12271@psf.upfronthosting.co.za>
Message-ID: <1307384678.19.0.211664254627.issue12271@psf.upfronthosting.co.za>


Vincent <v.claudic at free.fr> added the comment:

Hello Stefan,

Thanks a lot for your time and answer, but here are some additional information regarding the requires "panel.h" file. I've just launched a find command onto my ia64 server, and here is the result:

hesione:/ # find / -name "panel.h"
/usr/include/ncurses/panel.h
/usr/include/ncurses6/ncurses/panel.h
/usr/include/ncurses6/ncursesw/panel.h
/usr/include/ncursesw/panel.h
/usr/src/linux-2.6.32.12-0.7-obj/ia64/default/include/config/panel.h

As you may have also observed, the build command is claiming also ncurses, which is installed.

hesione:~ # rpm -qa|grep ncurses
yast2-ncurses-pkg-2.17.16-0.1.77
libncurses6-5.6-90.55
ncurses-devel-5.6-90.55
libncurses5-5.6-90.55
yast2-ncurses-2.17.17-0.4.38
ncurses-utils-5.6-90.55
libncurses5-x86-5.6-90.55
libncurses6-x86-5.6-90.55

Any further information will be welcome.

Thanks again for your patience, time and answer.

All the best,

Vincent

----------
status: pending -> open

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

From report at bugs.python.org  Mon Jun  6 20:29:12 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 06 Jun 2011 18:29:12 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <1307384952.49.0.89743424616.issue12021@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> I think duplicating it is fine, since the code is probably simple anyway

Added a new patch. I duplicated the None converting logic in _io/_iomodule.c to mmapmodule.c, changed the doc to say "read([n])", and expanded the test cases a bit.

----------

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

From report at bugs.python.org  Mon Jun  6 20:47:57 2011
From: report at bugs.python.org (Eli Collins)
Date: Mon, 06 Jun 2011 18:47:57 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1307386077.6.0.374242146265.issue12242@psf.upfronthosting.co.za>


Eli Collins <elic at assurancetechnologies.com> added the comment:

> What would the value be for non-C Python implementations?

I'm not really sure how this idea could have any value for those implementations, at least for the ones that can't make use of C extensions at all (I think PyPy can; so I guess that would leave Jython & IronPython). Then again, I don't see how anything inside "disutils2.compiler" could be relevant to those implementations either, so maybe I don't understand the question. 

> If the need for compiler-specific options is very common, we could
> consider either improving the compiler system or implement this
> request; if it?s not common, letting people use hooks would be enough.

I'm not entirely sure how common this is; even within those people who write C extensions, but I'm pretty sure some problems are unavoidable, such as compiler-specific options when linking to external libraries or compiler-specific ways of specifying compatibility options. Case in point: this stackoverflow question ( http://stackoverflow.com/questions/724664/python-distutils-how-to-get-a-compiler-that-is-going-to-be-used ) had a few solutions... and it seems to me that the cleanest one (from 'Jon') made much more sense as an environment marker. 

A similar case is this email thread ( http://comments.gmane.org/gmane.comp.python.devel/123768 ), which presents a situation where the person needs to set different options for a specific *version* of a compiler. In that case, the main solution people proposed was "see if setup() fails, and try again with different options". This is the same solution SQLAlchemy & SimpleJson have been using to implement "optional" c extensions under distutils1; and I wasn't sure if hacks like that were even going to be possible using the new hooks system.

Mind you, the person in that email thread needed to distinguish different *versions* of particular compilers, which I didn't propose in this issue - mainly because the compilers already have unique names assigned to them, and would only require making that info available; whereas gathering version strings and comparing them would require much more work & testing to implement properly.

----------

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

From report at bugs.python.org  Mon Jun  6 20:48:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Jun 2011 18:48:39 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <1307386119.78.0.434414784195.issue12021@psf.upfronthosting.co.za>


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

Didn't you forget to attach the patch?

----------

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

From report at bugs.python.org  Mon Jun  6 20:56:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 06 Jun 2011 18:56:31 +0000
Subject: [issue10115] Support accept4() for atomic setting of flags at socket
	creation
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1307386591.21.0.0864111372081.issue10115@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

@nvetoshkin
Could you update your patch against py3k?

I've got a couple comments (can't login to Rietveld, it's probably due to the change of my tracker account name):

if(flags & ~(SOCK_NONBLOCK | SOCK_CLOEXEC)) {
    PyErr_SetString(PyExc_ValueError,
        "Wrong flag value");
    return NULL;
}

I'm not sure that's necessary:
- accept4() can sanitize its input itself if necessary (will fail with EINVAL)
- if some flag is added, or another OS doesn't use the same flags, it'll fall out of sync


#ifdef HAVE_ACCEPT4
         /* These flags are not inherited after accept */
         type &= ~(SOCK_NONBLOCK & SOCK_CLOEXEC);
#endif /* HAVE_ACCEPT4 */

SOCK_NONBLOCK & SOCK_CLOEXEC == 0, so this doesn't do much.
Second, you should probably reuse what's done in Lib/socket.py for timeout inheritance upon accept (except that here you certainly don't want to set the socket to blocking if SOCK_NONBLOCK flag is passed).

You should add a test for that: have a look at test_pipe2 in Lib/test/test_posix.py.

----------

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

From report at bugs.python.org  Mon Jun  6 20:59:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Jun 2011 18:59:36 +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: <1307386776.33.0.623021006981.issue9205@psf.upfronthosting.co.za>


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

Ok, the dependencies are now committed. Here is a new patch addressing Charles-Fran?ois' comments: select() is now called before each call to read() when sentinels are given, to avoid race conditions.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file22266/sentinels5.patch

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

From report at bugs.python.org  Mon Jun  6 21:10:25 2011
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 06 Jun 2011 19:10:25 +0000
Subject: [issue12246] Warn when trying to install third-party module from an
	uninstalled checkout
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307387425.26.0.470664749313.issue12246@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

Find attached.

----------
Added file: http://bugs.python.org/file22267/display-warning_try2.diff

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

From report at bugs.python.org  Mon Jun  6 21:19:47 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 06 Jun 2011 19:19:47 +0000
Subject: [issue12232] embedded python import cmath
In-Reply-To: <1306888300.23.0.381408538703.issue12232@psf.upfronthosting.co.za>
Message-ID: <1307387987.63.0.949419672572.issue12232@psf.upfronthosting.co.za>


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

Is it possible that the problem is related to floating point exceptions?
A quick Google search showed similar issue in another embedded library:
http://www.softintegration.com/support/faq/embed.html#borland

It seems important to add this instruction:
   _control87(MCW_EM, MCW_EM);
Can you try and modify your program accordingly?

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

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

From report at bugs.python.org  Mon Jun  6 21:51:01 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 06 Jun 2011 19:51:01 +0000
Subject: [issue12232] embedded python import cmath
In-Reply-To: <1306888300.23.0.381408538703.issue12232@psf.upfronthosting.co.za>
Message-ID: <1307389861.74.0.374212174713.issue12232@psf.upfronthosting.co.za>


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

> Is it possible that the problem is related to floating point exceptions?

Hmm.  It's possible, but it's still a bit surprising that the crash occurs at import time rather than when calling one of the cmath functions.  But it's very possible that there are some missing PyFPE_START_PROTECT macros in the cmath source.

BTW, if the problem *is* in cmath, it's likely to also occur with Python 2.7:  that module changed very little between 2.6 and 2.7.

----------

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

From report at bugs.python.org  Mon Jun  6 21:52:28 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Jun 2011 19:52:28 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1307389948.75.0.639285536337.issue7511@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

mike bayer wrote:
> > 
> > mike bayer <mike_mp at zzzcomputing.com> added the comment:
> > 
> > regarding "hey this is an MS bug not Python", projects which feature optional C extensions are starting to apply workarounds for the issue on their end (I will need to commit a specific catch for this to SQLAlchemy) - users need to install our software and we need to detect compilation failures as a sign to move on without it.   I think it's preferable for Python distutils to work around an MS issue rather than N projects having to work around an MS issue exposed through distutils.  Seems like this bug has been out there a real long time...bump ?
This is not really an MS issue. Setting up the environment to be
able to compile extensions is a prerequisite on most platforms and
with most compilers.

MS VC++ supports having multiple compiler versions on the same
machine and allow compiling to x86, x64 and ia64 (at least
in more recent VC++ versions).

I think it's fair to ask the user to setup the environment correctly
before running "python setup.py install", since distutils doesn't
really know which compiler to use - e.g. you could be cross-compiling
for x64 on an x86 machine, or you may want to use VC 2008 instead of
a more recently installed VC 2010.

Wouldn't it be better to have distutils tell the user about the
possible options, instead of guessing and then possibly compiling
extensions which later on don't import or import, but don't work
as expected ?

Regarding the latest patch: This is not the right approach, since
find_vcvarsall() is supposed to return the path to the vcvarsall.bat
file and not an architecture specific setup file. It is later
called with the arch identifier, which the arch specific setup files
don't check or use.

Also note that vcvarsall.bat can take these options:

   x86 (default), x64, amd64, x86_amd64, ia64, x86_ia64

The x86_* options setup the cross compilers.

----------
nosy: +lemburg

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

From report at bugs.python.org  Mon Jun  6 21:55:45 2011
From: report at bugs.python.org (Ryan Seto)
Date: Mon, 06 Jun 2011 19:55:45 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1307390145.65.0.64265182226.issue7511@psf.upfronthosting.co.za>


Changes by Ryan Seto <mr.werewolf at gmail.com>:


----------
nosy:  -MrWerewolf

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

From report at bugs.python.org  Mon Jun  6 21:56:33 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 06 Jun 2011 19:56:33 +0000
Subject: [issue12232] embedded python import cmath
In-Reply-To: <1306888300.23.0.381408538703.issue12232@psf.upfronthosting.co.za>
Message-ID: <1307390193.54.0.895385044013.issue12232@psf.upfronthosting.co.za>


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

Looking at the cmath source, I'd be a bit suspicious that either the Py_NAN or the Py_HUGE_VAL macro (or both) is triggering an FPE.  Both those values are used during module initialization.

----------

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

From report at bugs.python.org  Mon Jun  6 21:59:27 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 06 Jun 2011 19:59:27 +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: <1307390367.38.0.705241298619.issue11802@psf.upfronthosting.co.za>


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

Nadeem, I want to review this but won't have a chance to do it right away.  Offhand, it seems like we could use the existing functools.lru_cache() for this if the stats were included as part of the key:  cache[f1, f2, s1, s2]=outcome.

Also, I want to take a fresh look at the cache strategy (saving diffs of two files vs saving file contents individually) and think about whether than makes any sense at all for real world use cases (is there a common need to compare the same file pairs over and over again or is the typical use the comparison of many different file pairs).   There may even be a better way to approach the underlying problem using hashes of entire files (md5, sha1, etc).

----------
assignee: nadeem.vawda -> rhettinger
resolution:  -> later

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

From report at bugs.python.org  Mon Jun  6 22:17:36 2011
From: report at bugs.python.org (jeff deifik)
Date: Mon, 06 Jun 2011 20:17:36 +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: <1307391456.64.0.628906422109.issue11802@psf.upfronthosting.co.za>


jeff deifik <jeff at jeffunit.com> added the comment:

There are many possible solutions to this problem.
Personally, I think mine is the simplest, though it changes the API.

However, there have been several suggestions on simple fixes that don't change the API, all of which fix the resource leak.

Doing nothing will not fix the resource leak.

How about a simple fix right now, using a lru cache, fixing all versions of Python, and perhaps come up with a superior solution at a later date?

----------

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

From report at bugs.python.org  Mon Jun  6 22:28:44 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 06 Jun 2011 20:28:44 +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: <1307392124.02.0.874982657442.issue11802@psf.upfronthosting.co.za>


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

We will do something.  The next release isn't for a while, so there is time to put thought into it rather than making an immediate check-in.

----------

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

From report at bugs.python.org  Mon Jun  6 22:44:05 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 06 Jun 2011 20:44:05 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1307393045.28.0.758573084859.issue7511@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Marc-Andre Lemburg <report at bugs.python.org> wrote:
> Wouldn't it be better to have distutils tell the user about the
> possible options, instead of guessing and then possibly compiling
> extensions which later on don't import or import, but don't work
> as expected ?

That would be an option, yes.


> Regarding the latest patch: This is not the right approach, since
> find_vcvarsall() is supposed to return the path to the vcvarsall.bat
> file and not an architecture specific setup file. It is later
> called with the arch identifier, which the arch specific setup files
> don't check or use.

The patch does not change anything for Visual Studio Pro. In Visual Studio
Express (+SDK) vcvarsall.bat is broken, so the architecture specific setup
files have to be used (they also work with a superfluous parameter).


> Also note that vcvarsall.bat can take these options:
>
>    x86 (default), x64, amd64, x86_amd64, ia64, x86_ia64
>
> The x86_* options setup the cross compilers.

I think the patch covers all architecture specific files that are
present in the Visual Studio Express + SDK setup.

Visual Studio Pro is protected from all changes by checking for
the presence of the file bin\amd64\vcvarsamd64.bat. This
could probably be done more elegantly by using some obscure
registry value.



As Thorsten mentioned, another option would be to copy bin\vcvars64.bat
to bin\amd64\vcvarsamd64.bat if the latter is not present.

This is harmless, but it is perhaps not really the business of Python
to mess with existing installs.

----------

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

From report at bugs.python.org  Mon Jun  6 23:04:40 2011
From: report at bugs.python.org (mike bayer)
Date: Mon, 06 Jun 2011 21:04:40 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1307394280.23.0.43028235383.issue7511@psf.upfronthosting.co.za>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

> I think it's fair to ask the user to setup the environment correctly
before running "python setup.py install"

We're supporting automatic fallback to non-C install for those environments that don't support it.   We're just looking for a predictable CCompilerError to be raised for conditions like this rather than a ValueError where we have to parse the string message.

----------

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

From report at bugs.python.org  Mon Jun  6 23:09:35 2011
From: report at bugs.python.org (Jack Eisenbach)
Date: Mon, 06 Jun 2011 21:09:35 +0000
Subject: [issue12272] Python 2.7.1 version conflict for package "Tcl" on
	Windows 7
In-Reply-To: <1307394575.29.0.810712086892.issue12272@psf.upfronthosting.co.za>
Message-ID: <1307394575.29.0.810712086892.issue12272@psf.upfronthosting.co.za>


New submission from Jack Eisenbach <jackie3 at cox.net>:

I wrote a Tkinter application that runs fine with Python 2.6.5 and 2.6.6 on a Windows 7 (32-bit version) machine. The same app fails with 2.7.1. Below is the debug output:

c:\ISS\ledmatrix>led-display.py
Traceback (most recent call last):
  File "ledmatrix.py", line 2263, in <module>
    LEDMatrix()
  File "ledmatrix.py", line 1427, in LEDMatrix
    root = Tk()
  File "C:\Python26\lib\lib-tk\Tkinter.py", line 1643, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following directories:
    {C:\Python27\tcl\tcl8.5} C:/Python26/lib/tcl8.5 C:/lib/tcl8.5 C:/lib/tcl8.5 C:/library C:/library C:/tcl8.5.8/library C:/tcl8.5.8/library

C:/Python27/tcl/tcl8.5/init.tcl: version conflict for package "Tcl": have 8.5.8, need exactly 8.5.2
version conflict for package "Tcl": have 8.5.8, need exactly 8.5.2
    while executing
"package require -exact Tcl 8.5.2"
    (file "C:/Python27/tcl/tcl8.5/init.tcl" line 20)
    invoked from within
"source C:/Python27/tcl/tcl8.5/init.tcl"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list source $tclfile]"


This probably means that Tcl wasn't installed properly.

----------
components: Tkinter
messages: 137778
nosy: jackie3
priority: normal
severity: normal
status: open
title: Python 2.7.1 version conflict for package "Tcl" on Windows 7
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun  6 23:11:17 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Jun 2011 21:11:17 +0000
Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with
	VC Express
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1307394677.32.0.956164686805.issue7511@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Stefan Krah wrote:
> > 
> > Stefan Krah <stefan-usenet at bytereef.org> added the comment:
> > 
> > Marc-Andre Lemburg <report at bugs.python.org> wrote:
>> >> Wouldn't it be better to have distutils tell the user about the
>> >> possible options, instead of guessing and then possibly compiling
>> >> extensions which later on don't import or import, but don't work
>> >> as expected ?
> > 
> > That would be an option, yes.
> > 
> > 
>> >> Regarding the latest patch: This is not the right approach, since
>> >> find_vcvarsall() is supposed to return the path to the vcvarsall.bat
>> >> file and not an architecture specific setup file. It is later
>> >> called with the arch identifier, which the arch specific setup files
>> >> don't check or use.
> > 
> > The patch does not change anything for Visual Studio Pro. In Visual Studio
> > Express (+SDK) vcvarsall.bat is broken, so the architecture specific setup
> > files have to be used (they also work with a superfluous parameter).

I guess what I wanted to say is that find_vcvarsall() should
return None for VC Express and code using it should then
revert to using a new find_vcvars() function, which takes the
architecture as parameter and returns the path to the correct
architecture setup file.

Hacking the support into find_vcvarsall() is not the right
approach. You have to add this support one level further up.

>> >> Also note that vcvarsall.bat can take these options:
>> >>
>> >>    x86 (default), x64, amd64, x86_amd64, ia64, x86_ia64
>> >>
>> >> The x86_* options setup the cross compilers.
> > 
> > I think the patch covers all architecture specific files that are
> > present in the Visual Studio Express + SDK setup.

Right, but it doesn't cover the ones available in VS Pro (see
above), which it should for completeness.

> > Visual Studio Pro is protected from all changes by checking for
> > the presence of the file bin\amd64\vcvarsamd64.bat. This
> > could probably be done more elegantly by using some obscure
> > registry value.
> > 
> > 
> > 
> > As Thorsten mentioned, another option would be to copy bin\vcvars64.bat
> > to bin\amd64\vcvarsamd64.bat if the latter is not present.
> > 
> > This is harmless, but it is perhaps not really the business of Python
> > to mess with existing installs.

Not a good idea :-)

PS: Changing the title, since I keep getting the following error messages from the email interface:

There were problems handling your subject line argument list:
- not of form [arg=value,value,...;arg=value,value,...]

Subject was: "Re: [issue7511] msvc9compiler.py: ValueError: [u'path']"

----------
title: msvc9compiler.py: ValueError: [u'path'] -> msvc9compiler.py: ValueError when trying to compile with VC Express

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

From report at bugs.python.org  Tue Jun  7 00:55:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Jun 2011 22:55:53 +0000
Subject: [issue9302] distutils API Reference: setup() and Extension
	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1307400953.31.0.120872944509.issue9302@psf.upfronthosting.co.za>


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

Why was this issue set to pending?  No motivating comment was added.

----------
nosy: +r.david.murray
status: pending -> open

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

From report at bugs.python.org  Tue Jun  7 01:19:38 2011
From: report at bugs.python.org (Nick ODell)
Date: Mon, 06 Jun 2011 23:19:38 +0000
Subject: [issue10405] IDLE breakpoint facility undocumented
In-Reply-To: <1289638474.62.0.690259510388.issue10405@psf.upfronthosting.co.za>
Message-ID: <1307402378.49.0.553679486005.issue10405@psf.upfronthosting.co.za>


Nick ODell <nickodell at gmail.com> added the comment:

I've added a short note regarding breakpoints in Doc/library/idle.rst

Ned, I'm not an experienced user with IDLE by any means, but I think some documentation is better than none, no?

----------
nosy: +Nick.ODell
Added file: http://bugs.python.org/file22268/idle.rst

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

From report at bugs.python.org  Tue Jun  7 02:30:19 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 07 Jun 2011 00:30:19 +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: <1307406619.01.0.302337335653.issue11802@psf.upfronthosting.co.za>


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

> Also, I want to take a fresh look at the cache strategy (saving diffs
> of two files vs saving file contents individually) and think about
> whether than makes any sense at all for real world use cases
> (is there a common need to compare the same file pairs over and over
> again or is the typical use the comparison of many different file
> pairs).   There may even be a better way to approach the underlying
> problem using hashes of entire files (md5, sha1, etc).

I like that idea. A hash-based approach could speed up the detection of
non-equal files quite a bit.

----------

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

From report at bugs.python.org  Tue Jun  7 03:23:09 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jun 2011 01:23:09 +0000
Subject: [issue12232] embedded python import cmath
In-Reply-To: <1306888300.23.0.381408538703.issue12232@psf.upfronthosting.co.za>
Message-ID: <1307409789.07.0.0597439317167.issue12232@psf.upfronthosting.co.za>


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


----------
versions: +Python 2.7

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

From report at bugs.python.org  Tue Jun  7 04:07:41 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 07 Jun 2011 02:07:41 +0000
Subject: [issue12019] Dead or buggy code in importlib.test.__main__
In-Reply-To: <1304698107.84.0.876175210451.issue12019@psf.upfronthosting.co.za>
Message-ID: <1307412461.47.0.242418089924.issue12019@psf.upfronthosting.co.za>


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

Sure, but I'm not even sure it's worth the hassle of dealing with the merge. If you want to put in the time then that's fine, but I don't think it's worth it.

----------

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

From report at bugs.python.org  Tue Jun  7 04:33:54 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Jun 2011 02:33:54 +0000
Subject: [issue11690] Devguide: Add "communication" FAQ
In-Reply-To: <1301188192.33.0.9529618781.issue11690@psf.upfronthosting.co.za>
Message-ID: <1307414034.89.0.885990505511.issue11690@psf.upfronthosting.co.za>


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

On a related note, http://docs.python.org/devguide/docquality.html should mention that the devguide itself lives in a different repo but the process is otherwise similar to contributing to the main docs.

----------

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

From report at bugs.python.org  Tue Jun  7 05:36:55 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Jun 2011 03:36:55 +0000
Subject: [issue11549] Rewrite peephole to work on AST
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1307417815.87.0.425050365345.issue11549@psf.upfronthosting.co.za>


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

Eugene raised the question of AST changes on python-dev [1] and the verdict was that so long as ast.__version__ is updated, AST clients will be able to cope with changes.

Benjamin Peterson made some subsequent changes to the AST (bringing the AST for try and with statements more in line with the concrete syntax, allowing source-to-source transforms to retain the original code structure).

This patch will probably need to be updated to be based on the latest version of the AST - I would be surprised if it applied cleanly to the current tip.

[1] http://mail.python.org/pipermail/python-dev/2011-April/110399.html

----------

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

From report at bugs.python.org  Tue Jun  7 06:12:14 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Jun 2011 04:12:14 +0000
Subject: [issue12273] Change ast.__version__ calculation to provide consistent
	ordering
In-Reply-To: <1307419934.4.0.45216742345.issue12273@psf.upfronthosting.co.za>
Message-ID: <1307419934.4.0.45216742345.issue12273@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Benjamin's AST modification checkins switched directly from the SVN revision number (as a string) to the hg revision hash.

While that preserves uniqueness, it makes ordering difficult to determine.

The last AST version in 3.2 was '82163' (and it was '82160' in 2.7).

I would like to change the version number calculation to something like:

  '9.x.y.zzzzzzz'

where

  9 is a prefix to get 3.3+ ast.__version__ values to sort higher than earlier versions
  x.y is the Python version so later versions sort higher than earlier versions in the future
  zzzzzz is the hg version id, so versions during development of a release remain unique, even if they can't be readily ordered.

This would require changes to ast.py (to add the 9.x.y prefix) and to release.py (to check that the 'x.y' prefix is correct in the current release)

----------
assignee: ncoghlan
components: Library (Lib)
messages: 137786
nosy: benjamin.peterson, brett.cannon, ncoghlan
priority: normal
severity: normal
status: open
title: Change ast.__version__ calculation to provide consistent ordering
versions: Python 3.3

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

From report at bugs.python.org  Tue Jun  7 06:44:54 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 07 Jun 2011 04:44:54 +0000
Subject: [issue12268] file readline,
	readlines & readall methods can lose data on EINTR
In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za>
Message-ID: <1307421894.04.0.291682545575.issue12268@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jun  7 07:46:30 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 07 Jun 2011 05:46:30 +0000
Subject: [issue12273] Change ast.__version__ calculation	to provide consistent
	ordering
In-Reply-To: <1307419934.4.0.45216742345.issue12273@psf.upfronthosting.co.za>
Message-ID: <4DEDBB34.9000302@v.loewis.de>


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

> I would like to change the version number calculation to something
> like:
> 
> '9.x.y.zzzzzzz'
> 
> where
> 
> 9 is a prefix to get 3.3+ ast.__version__ values to sort higher than
> earlier versions x.y is the Python version so later versions sort
> higher than earlier versions in the future zzzzzz is the hg version
> id, so versions during development of a release remain unique, even
> if they can't be readily ordered.

I'd drop the 9. part. People doing comparison on these numbers possibly
performed int() conversions first (expecting that svn revisions might
have exceeded 100,000 some day); they would have to special-case 3.3
anyway. Also, in the long run, the 2.x/3.1/3.2 copies of ast will be
gone, and we are stuck with this odd prefix.

OTOH, most people probably don't do ordering comparisons at all, but
have explicit lists of versions they support (barking if it's an
unknown version); those won't be helped by the 9. prefix at all.

> This would require changes to ast.py (to add the 9.x.y prefix) and to
> release.py (to check that the 'x.y' prefix is correct in the current
> release)

I'd synthesize x.y from patchlevel.h, in which case it would be fully
automatic again.

----------
nosy: +loewis
title: Change ast.__version__ calculation to provide consistent ordering -> Change ast.__version__ calculation	to provide consistent ordering

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

From report at bugs.python.org  Tue Jun  7 07:53:33 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 07 Jun 2011 05:53:33 +0000
Subject: [issue11549] Build-out an AST optimizer,
	moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1307426013.9.0.544131561376.issue11549@psf.upfronthosting.co.za>


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

Updated the title to reflect that the peephole optimizer will likely continue to exist but in a much simpler form.  Some complex peephole optimization such as constant folding can be handled more easily and more robustly at the AST level.

Other minor peephole optimizations such as jump-to-jump simplification as still bytecode level optimizations (ones that improve the quality of the generated code without visibility to higher level semantics).

----------
title: Rewrite peephole to work on AST -> Build-out an AST optimizer, moving some functionality out of the peephole optimizer

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

From report at bugs.python.org  Tue Jun  7 08:16:07 2011
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 07 Jun 2011 06:16:07 +0000
Subject: [issue12274] "Print window" menu on IDLE aborts whole application
In-Reply-To: <1307427367.68.0.910605365077.issue12274@psf.upfronthosting.co.za>
Message-ID: <1307427367.68.0.910605365077.issue12274@psf.upfronthosting.co.za>


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

On Windows, IDLE closes all open windows and exits completely, without any error message, when selecting the "Print window" menu command.

Starting IDLE from inside a console, one can see the error message:

Exception in Tkinter callback
Traceback (most recent call last):
  File "D:\apps\python32\lib\tkinter\__init__.py", line 1399, in __call__
    return self.func(*args)
  File "D:\apps\python32\lib\idlelib\IOBinding.py", line 453, in print_window
    command = idleConf.GetOption('main','General','print-command-win')
  File "D:\apps\python32\lib\idlelib\configHandler.py", line 245, in GetOption
    type=type, raw=raw)
  File "D:\apps\python32\lib\idlelib\configHandler.py", line 54, in Get
    return self.get(section, option, raw=raw)
  File "D:\apps\python32\lib\configparser.py", line 789, in get
    d)
  File "D:\apps\python32\lib\configparser.py", line 391, in before_get
    self._interpolate_some(parser, option, L, value, section, defaults, 1)
  File "D:\apps\python32\lib\configparser.py", line 440, in _interpolate_some
    "found: %r" % (rest,))
configparser.InterpolationSyntaxError: '%' must be followed by '%' or '(', found
: '%s'


It is trying to read this entry from the config-main.def file:

[General]
print-command-posix=lpr %s
print-command-win=start /min notepad /p %s

For a ConfigParser file, those %s should be %%s instead. Previous IDLE versions (2.7 and 3.1) read the same entry without problem; I suspect they were using a RawConfigParser or processing the entry in a different way.

As a workaround, replacing %s with %%s in config-main.def is enough, until the code gets fixed.

----------
components: IDLE
messages: 137789
nosy: gagenellina
priority: normal
severity: normal
status: open
title: "Print window" menu on IDLE aborts whole application
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Jun  7 08:18:19 2011
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 07 Jun 2011 06:18:19 +0000
Subject: [issue12274] "Print window" menu on IDLE aborts whole application
In-Reply-To: <1307427367.68.0.910605365077.issue12274@psf.upfronthosting.co.za>
Message-ID: <1307427499.1.0.490210311055.issue12274@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Note: There is a much bigger problem here: IDLE should not abort abruptly in such cases, without any error indication.

----------

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

From report at bugs.python.org  Tue Jun  7 09:10:18 2011
From: report at bugs.python.org (lilydjwg)
Date: Tue, 07 Jun 2011 07:10:18 +0000
Subject: [issue12275] urllib.request.HTTPRedirectHandler won't redirect to a
	URL with only path but not domain
In-Reply-To: <1307430618.09.0.225442782299.issue12275@psf.upfronthosting.co.za>
Message-ID: <1307430618.09.0.225442782299.issue12275@psf.upfronthosting.co.za>


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

On redirecting to a url like '/login', at around line 556 of request.py it will raise an HTTPError. The sys.verrsion is

  Python 3.2 (r32:88445, Apr 15 2011, 11:20:08) 
  [GCC 4.5.2 20110127 (prerelease)] on linux2

----------
components: Library (Lib)
messages: 137791
nosy: lilydjwg
priority: normal
severity: normal
status: open
title: urllib.request.HTTPRedirectHandler won't redirect to a URL with only path but not domain
versions: Python 3.2

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

From report at bugs.python.org  Tue Jun  7 10:48:21 2011
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 07 Jun 2011 08:48:21 +0000
Subject: [issue12276] 3.x ignores sys.tracebacklimit=0
In-Reply-To: <1307436501.83.0.59684150491.issue12276@psf.upfronthosting.co.za>
Message-ID: <1307436501.83.0.59684150491.issue12276@psf.upfronthosting.co.za>


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

Python 3.x doesn't honor sys.tracebacklimit=0

According to 
http://docs.python.org/py3k/library/sys.html#sys.tracebacklimit
when set to 0, it should not print any stack trace, but it does.

Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
p3> import sys
p3> sys.tracebacklimit = 0
p3>
p3> def f(x):
...   return f(x-1) if x else 0/0
...
p3> f(5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in f
  File "<stdin>", line 2, in f
  File "<stdin>", line 2, in f
  File "<stdin>", line 2, in f
  File "<stdin>", line 2, in f
  File "<stdin>", line 2, in f
ZeroDivisionError: division by zero
p3>

----------
components: Interpreter Core
files: tracebacklimitbug.py
messages: 137792
nosy: gagenellina
priority: normal
severity: normal
status: open
title: 3.x ignores sys.tracebacklimit=0
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file22269/tracebacklimitbug.py

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

From report at bugs.python.org  Tue Jun  7 10:50:18 2011
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 07 Jun 2011 08:50:18 +0000
Subject: [issue12276] 3.x ignores sys.tracebacklimit=0
In-Reply-To: <1307436501.83.0.59684150491.issue12276@psf.upfronthosting.co.za>
Message-ID: <1307436618.56.0.694549277941.issue12276@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Originally reported by Thorsten Kampe in comp.lang.python 2011-5-27
<http://permalink.gmane.org/gmane.comp.python.general/691496>

----------

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

From report at bugs.python.org  Tue Jun  7 11:10:18 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 07 Jun 2011 09:10:18 +0000
Subject: [issue12276] 3.x ignores sys.tracebacklimit=0
In-Reply-To: <1307436501.83.0.59684150491.issue12276@psf.upfronthosting.co.za>
Message-ID: <1307437818.68.0.344583001354.issue12276@psf.upfronthosting.co.za>


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

This was changed a long time ago with 565012d1123d

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

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

From report at bugs.python.org  Tue Jun  7 11:22:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jun 2011 09:22:27 +0000
Subject: [issue12276] 3.x ignores sys.tracebacklimit=0
In-Reply-To: <1307436501.83.0.59684150491.issue12276@psf.upfronthosting.co.za>
Message-ID: <1307438547.4.0.0555644368083.issue12276@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/issue12276>
_______________________________________

From report at bugs.python.org  Tue Jun  7 11:45:51 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 07 Jun 2011 09:45:51 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

http://docs.python.org/release/2.6.6/library/os.html?highlight=os.walk#os.walk

Click the above link and note the 5th paragraph which goes "By default errors from the listdir() call are ignored."

Please fix it to "By default, errors from the listdir() call are ignored."

So add a comma after "By default," Thanks.

----------
assignee: docs at python
components: Documentation
messages: 137795
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: Missing comma in os.walk docs
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/issue12277>
_______________________________________

From report at bugs.python.org  Tue Jun  7 11:46:44 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 07 Jun 2011 09:46:44 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1307440004.57.0.773594740281.issue12084@psf.upfronthosting.co.za>


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

Any Windows person going to review this one?

----------

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

From report at bugs.python.org  Tue Jun  7 11:49:16 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 07 Jun 2011 09:49:16 +0000
Subject: [issue9284] inspect.findsource() cannot find source for doctest code
In-Reply-To: <1279372617.05.0.528440876901.issue9284@psf.upfronthosting.co.za>
Message-ID: <1307440156.68.0.948227474986.issue9284@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Here's an attempted patch against 2.7. It seemed nice to put the test in test_doctest, but maybe it belongs in inspect...

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file22270/issue9284.diff

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

From report at bugs.python.org  Tue Jun  7 11:55:21 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 07 Jun 2011 09:55:21 +0000
Subject: [issue12019] Dead or buggy code in importlib.test.__main__
In-Reply-To: <1304698107.84.0.876175210451.issue12019@psf.upfronthosting.co.za>
Message-ID: <1307440521.41.0.0697733354513.issue12019@psf.upfronthosting.co.za>


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

If it's a minor cleanup and not a bugfix, why should it go into a branch that receives bugfixes only?

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

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

From report at bugs.python.org  Tue Jun  7 11:57:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Jun 2011 09:57:39 +0000
Subject: [issue12268] file readline,
	readlines & readall methods can lose data on EINTR
In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za>
Message-ID: <1307440659.49.0.164883737505.issue12268@psf.upfronthosting.co.za>


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

I'm not sure why you're creating a separate test file. There are already signals-related tests in test_io. Also, perhaps you can reuse the idioms used there, rather than spawn subprocesses.

----------
stage:  -> patch review

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

From report at bugs.python.org  Tue Jun  7 12:11:16 2011
From: report at bugs.python.org (Tim Golden)
Date: Tue, 07 Jun 2011 10:11:16 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1307440004.57.0.773594740281.issue12084@psf.upfronthosting.co.za>
Message-ID: <4DEDF941.7080203@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

I'm just patching a clone now.

----------
nosy: +tim.golden

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

From report at bugs.python.org  Tue Jun  7 12:59:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jun 2011 10:59:55 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1307444395.99.0.918088582709.issue12084@psf.upfronthosting.co.za>


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

issue12084.diff:
 - test_os pass with patched Python 3.3 on Windows 7 64 bits (and on Linux, Debian Sid)
 - in test_os: "finally: os.remove(file1)"  fails with file1 doesn't exist: a new try/finally should be used after "with open(file1, "w") as f:" block, or support.unlink() should be used instead
 - the patch doesn't apply cleany on the default Mercurial branch (fail on posixmodule.c), can you update your patch?
 - posixmodule.c still refer to win32_lstat() in a comment (a comment just before the removed win32_lstat() function)
 - win32_stat() must fail if the conversion to wide character failed. win32_stat() should use PyUnicode_DecodeFSDefault() instead of mbstowcs_s(). PyUnicode_DecodeFSDefault() allocates the memory and handles errors correctly: raise a nice Python error on decoding error (it uses the strict error handler for MBCS encoding, the ANSI code page).

win32_stat() decodes "manually" the filename from the ANSI code page and use the wide character API, instead of using the ANSI API. It is a little bit different than what is done for other functions of the posix module: other functions use the ANSI API, as specified by the PEP 277.
http://www.python.org/dev/peps/pep-0277/

Well, this PEP was written in 2002 when the default string type in Python (2) was the byte string. In 2011, with Python 3, the default string type is a character string and I can easily understand that you prefer to simplify the code by using a single string type. I also remember a discussion about deprecating byte filenames in Python 3.

I would prefer to discuss this point (decode byte string from the ANSI code page) on the mailing, and maybe also update the PEP 277.

The main question for me is how the ANSI API handles undecodable bytes: does it raise an error or ignore them? For stat(), ignoring undecodable bytes means that stat() will raise a "file not found error".

Most ANSI code pages never fail with a decoding error because they are 8 bits encoding and all bytes are mapped to characters. They are some multibyte code pages (like UTF-8), but I don't think that any Windows use such code page *by default*. I don't even know if it's possible to use a multibyte code page as the ANSI code page.

(I didn't check the symlink algorithm, I only cares about Unicode :-D)

----------
nosy: +haypo

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

From report at bugs.python.org  Tue Jun  7 13:04:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Jun 2011 11:04:55 +0000
Subject: [issue12275] urllib.request.HTTPRedirectHandler won't redirect to a
	URL with only path but not domain
In-Reply-To: <1307430618.09.0.225442782299.issue12275@psf.upfronthosting.co.za>
Message-ID: <1307444695.26.0.50526491888.issue12275@psf.upfronthosting.co.za>


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

Well, the HTTP RFC does indicate that the redirection URI (in the Location header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30) must be an absolute URI, but I also agree that using a relative URI in that context is a common use-case supported by browsers, and it would be good to support it in the stdlib too.

----------
nosy: +orsenthil, pitrou
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.3

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

From report at bugs.python.org  Tue Jun  7 13:07:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jun 2011 11:07:23 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1307444843.44.0.830746910104.issue12084@psf.upfronthosting.co.za>


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

Win32SymlinkTests.test_rmdir_on_directory_link_to_missing_target() pass on my Windows 7 64 bits VM (with and without the patch), but is skipped:

    @unittest.skip("currently fails; consider for improvement")
    def test_rmdir_on_directory_link_to_missing_target(self):
        self._create_missing_dir_link()
        # consider allowing rmdir to remove directory links
        os.rmdir(self.missing_link)

On which OS does it fail? The skip may be changed to only skipped some Windows versions?

----------

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

From report at bugs.python.org  Tue Jun  7 13:08:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Jun 2011 11:08:05 +0000
Subject: [issue12238] Readline module loading in interactive mode
In-Reply-To: <1307015860.03.0.129842780518.issue12238@psf.upfronthosting.co.za>
Message-ID: <1307444885.55.0.481801696334.issue12238@psf.upfronthosting.co.za>


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

I don't think readline is "special-cased":

$ echo "1/0" > logging.py
$ cpython/default/python
Python 3.3a0 (default:d8502fee4638+, Jun  6 2011, 19:13:58) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "logging.py", line 1, in <module>
    1/0
ZeroDivisionError: division by zero

----------

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

From report at bugs.python.org  Tue Jun  7 13:11:58 2011
From: report at bugs.python.org (Tim Golden)
Date: Tue, 07 Jun 2011 11:11:58 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <4DEDF941.7080203@timgolden.me.uk>
Message-ID: <4DEE077A.4010600@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

All expected tests pass on 3.2 branch (Win7 32-bit). The patch doesn't 
apply cleanly to trunk; not sure if it's expected to or not. The code
looks ok on paper. I'll leave Victor to quibble over the Unicode stuff...

----------

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

From report at bugs.python.org  Tue Jun  7 13:16:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Jun 2011 11:16:05 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1307445365.99.0.689464535688.issue12226@psf.upfronthosting.co.za>


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

> If you make an HTTPS connection without checking the certificate, what 
> security does it add?

Well, it does prevent the most trivial class of attacks (sniffing).
That said, Python has support for certificate checking, especially in 3.2+, so you should use that. You could e.g. bundle the CACert root certificate with the distribution.

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

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

From report at bugs.python.org  Tue Jun  7 13:16:47 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Tue, 07 Jun 2011 11:16:47 +0000
Subject: [issue12278] Core mentorship mention in the devguide
In-Reply-To: <1307445407.08.0.276007268612.issue12278@psf.upfronthosting.co.za>
Message-ID: <1307445407.08.0.276007268612.issue12278@psf.upfronthosting.co.za>


New submission from Adam Woodbeck <adam.woodbeck at gmail.com>:

Jesse requested the devguide be updated to include a mention of the Python Mentors site.  The attached patch is my rough draft.

----------
components: Devguide
files: help.rst.patch
keywords: patch
messages: 137807
nosy: adam.woodbeck, ncoghlan
priority: normal
severity: normal
status: open
title: Core mentorship mention in the devguide
Added file: http://bugs.python.org/file22271/help.rst.patch

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

From report at bugs.python.org  Tue Jun  7 13:23:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Jun 2011 11:23:55 +0000
Subject: [issue12188] PEP 7, C style: add ++ policy and explanation
In-Reply-To: <1306433972.91.0.882585972593.issue12188@psf.upfronthosting.co.za>
Message-ID: <1307445835.82.0.81668559565.issue12188@psf.upfronthosting.co.za>


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

Indeed, I don't think that's appropriate. Also, it's not about ++ in general but a particular use of it.

----------
nosy: +gvanrossum, pitrou
resolution:  -> rejected
status: open -> pending
type:  -> feature request

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

From report at bugs.python.org  Tue Jun  7 13:36:32 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 07 Jun 2011 11:36:32 +0000
Subject: [issue12188] PEP 7, C style: add ++ policy and explanation
In-Reply-To: <1306433972.91.0.882585972593.issue12188@psf.upfronthosting.co.za>
Message-ID: <1307446592.87.0.435446903286.issue12188@psf.upfronthosting.co.za>


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

But don't you think we should put information like this somewhere, even if it's not in PEP 7? We've had a discussion about this particular issue (idiomatic pointer increments when appending to a buffer) at least twice, and there's also the recent "if (const == variable)" issue that feels similar to me.

It seems to me that recording these decisions somewhere has value, just so we don't have to revisit them.

----------
status: pending -> open

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

From report at bugs.python.org  Tue Jun  7 13:36:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Jun 2011 11:36:41 +0000
Subject: [issue12197] non-blocking SSL write in Windows sends large data but
	raises exception
In-Reply-To: <1306519609.32.0.152577977388.issue12197@psf.upfronthosting.co.za>
Message-ID: <1307446601.63.0.153023180063.issue12197@psf.upfronthosting.co.za>


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

Which version of Python are you testing on? It works fine using 3.2 and 3.3 here, under Windows 7 64-bit.

Anyway, I would suggest to batch your write in smaller chunks (say, 2048 bytes each). Also, you may try sendall() instead.

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

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

From report at bugs.python.org  Tue Jun  7 13:38:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Jun 2011 11:38:03 +0000
Subject: [issue11203] gzip doc is behind
In-Reply-To: <1297539632.81.0.320134391105.issue11203@psf.upfronthosting.co.za>
Message-ID: <1307446683.91.0.25156461461.issue11203@psf.upfronthosting.co.za>


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

The 3.x doc states that "GzipFile supports the io.BufferedIOBase interface, including iteration and the with statement. Only the truncate() method isn?t implemented". This implies that it also supports close().

----------
nosy: +pitrou
versions:  -Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jun  7 13:44:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Jun 2011 11:44:00 +0000
Subject: [issue12198] zipfile.py:1047: DeprecationWarning: 'H' format requires
	0 <= number <= 65535
In-Reply-To: <1306521866.64.0.0795641748962.issue12198@psf.upfronthosting.co.za>
Message-ID: <1307447040.05.0.927569783577.issue12198@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jun  7 13:45:39 2011
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Tue, 07 Jun 2011 11:45:39 +0000
Subject: [issue10115] Support accept4() for atomic setting of flags at socket
	creation
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1307447139.45.0.440649691058.issue10115@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Yes, I can.
We decided to expose accept4() as another socket method, not accept() replacement?

----------

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

From report at bugs.python.org  Tue Jun  7 13:47:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jun 2011 11:47:29 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1307447249.58.0.435099561518.issue12084@psf.upfronthosting.co.za>


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

Oh oh. The situation is not a simple as expected. 3 functions only accept Unicode strings and 3 other functions decode "manually" byte strings from the ANSI code page.

--

chdir(), rmdir(), unlink(), access(), chmod(), link(), listdir(), _getfullpath(), mkdir(), utime(), open(), startfile(), unlink(), stat() and lstat() use the ANSI or the wide character API depending on the type of the input arguments.

rename(), symlink() and putenv() only use the wide character API. They use convert_to_unicode() to convert input arguments to Unicode. Byte strings are decoded from the file system encoding using the strict error error.

system(), readlink() and unsetenv() only accept Unicode strings.

--

Possible bugs.

unlink() uses DeleteFileA() for byte string and Py_DeleteFileW() for unicode. Py_DeleteFileW() has a special case for symbolic links:

/* override the default DeleteFileW behavior so that directory
symlinks can be removed with this function, the same as with
Unix symlinks */

unsetenv() encodes the variable name to UTF-8, which looks wrong to me.

startfile() encodes the second argument (operation) to UTF-8 and then decode it from ASCII to get a wchar_t* string. Why not using simply the "u" format to support more than ASCII characters?

It's surprising that unsetenv() only accept Unicode strings, because this Python function uses a C function with a bytes API (unsetenv).

----------

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

From report at bugs.python.org  Tue Jun  7 13:51:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 07 Jun 2011 11:51:25 +0000
Subject: [issue12188] PEP 7, C style: add ++ policy and explanation
In-Reply-To: <1306433972.91.0.882585972593.issue12188@psf.upfronthosting.co.za>
Message-ID: <1307447485.75.0.601503213678.issue12188@psf.upfronthosting.co.za>


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

If there are a few of these idioms, I'm not against adding a new section  to PEP 7 (something like the "Programming Recommendations" section in the PEP 8).  It's just not worth doing it for the "*p++ = x;" idiom alone IMHO.

----------

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

From report at bugs.python.org  Tue Jun  7 13:53:11 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 07 Jun 2011 11:53:11 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1307447591.71.0.716156374117.issue12277@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Here's a patch.

----------
keywords: +patch
nosy: +petri.lehtinen
Added file: http://bugs.python.org/file22272/docs_os_walk_add_comma.patch

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

From report at bugs.python.org  Tue Jun  7 13:56:32 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 07 Jun 2011 11:56:32 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1307447792.3.0.868393177967.issue12277@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
versions:  -Python 2.6, Python 3.4

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

From report at bugs.python.org  Tue Jun  7 13:56:43 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 07 Jun 2011 11:56:43 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1307447803.82.0.336997056148.issue12277@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
versions:  -Python 3.1

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

From report at bugs.python.org  Tue Jun  7 13:58:54 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 07 Jun 2011 11:58:54 +0000
Subject: [issue11669] Clarify Lang Ref "Compound statements" footnote
In-Reply-To: <1301042574.67.0.975748752077.issue11669@psf.upfronthosting.co.za>
Message-ID: <1307447934.84.0.719277268572.issue11669@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Keywords suggest that there should to be a patch here. Where is it?

----------
nosy: +petri.lehtinen

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

From report at bugs.python.org  Tue Jun  7 14:00:20 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 07 Jun 2011 12:00:20 +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: <1307448020.58.0.187370371329.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Aehm, note that Apple has fixed the mmap(2) bug!!
I'm still surprised and can't really believe it, but it's true!
Just in case you're interested, i'll apply an updated patch.

Maybe Ned Deily should have a look at the version check, which
does not apply yet, but i don't know any other way to perform exact
version checking.  (Using 10.6.7 is not enough, it must be 10.7.0;
uname -a yet reports that all through, but no CPP symbol does!?)

----------
Added file: http://bugs.python.org/file22273/11277.apple-fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Jun  7 14:02:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Jun 2011 12:02:53 +0000
Subject: [issue12188] PEP 7, C style: add ++ policy and explanation
In-Reply-To: <1307447485.75.0.601503213678.issue12188@psf.upfronthosting.co.za>
Message-ID: <1307448169.3530.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If there are a few of these idioms, I'm not against adding a new
> section  to PEP 7 (something like the "Programming Recommendations"
> section in the PEP 8).  It's just not worth doing it for the "*p++ =
> x;" idiom alone IMHO.

If these are recommandations, perhaps we should put them in the devguide
instead?

But I agree that it's not worth doing it only for "*p++" anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12188>
_______________________________________

From report at bugs.python.org  Tue Jun  7 14:17:43 2011
From: report at bugs.python.org (Eugene Toder)
Date: Tue, 07 Jun 2011 12:17:43 +0000
Subject: [issue11549] Build-out an AST optimizer,
	moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1307449063.71.0.620037498555.issue11549@psf.upfronthosting.co.za>


Eugene Toder <eltoder at gmail.com> added the comment:

Nick, if there's an interest in reviewing the patch I can update the it. I doubt it needs a lot of changes, given that visitor is auto-generated.

Raymond, the patch contains a rewrite of low-level optimizations to work before byte code generation, which simplifies them a great deal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11549>
_______________________________________

From report at bugs.python.org  Tue Jun  7 14:46:18 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Jun 2011 12:46:18 +0000
Subject: [issue12274] "Print window" menu on IDLE aborts whole application
In-Reply-To: <1307427367.68.0.910605365077.issue12274@psf.upfronthosting.co.za>
Message-ID: <1307450778.52.0.0900415984091.issue12274@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12274>
_______________________________________

From report at bugs.python.org  Tue Jun  7 15:06:29 2011
From: report at bugs.python.org (Pascal Chambon)
Date: Tue, 07 Jun 2011 13:06:29 +0000
Subject: [issue5906] Risk of confusion in multiprocessing module - daemonic
	processes
In-Reply-To: <1241281680.28.0.426890622653.issue5906@psf.upfronthosting.co.za>
Message-ID: <1307451989.49.0.0517237731357.issue5906@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

I've just crossed again the doc of the daemon flag (http://docs.python.org/library/multiprocessing.html), and it's still quite confusing to newcomers.

daemon
    The process?s daemon flag, a Boolean value. This must be set before start() is called.
    The initial value is inherited from the creating process. [1]
    When a process exits, it attempts to terminate all of its daemonic child processes.

[1] this sentence is weird: since daemonic processes are not allowed to have children, isn't this flag always False in a new Process instance ?
[2] typo, it meant "all of its NON-daemonic child processes" instead, didn't it ?

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5906>
_______________________________________

From report at bugs.python.org  Tue Jun  7 15:13:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Jun 2011 13:13:01 +0000
Subject: [issue12238] Readline module loading in interactive mode
In-Reply-To: <1307015860.03.0.129842780518.issue12238@psf.upfronthosting.co.za>
Message-ID: <1307452381.21.0.720000044317.issue12238@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Python 3.3a0 (default:7323a865457a+, Jun  5 2011, 19:22:38) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.modules['logging']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'logging'
>>> sys.modules['os']
<module 'os' from '/home/rdmurray/python/p33/Lib/os.py'>

The difference is that logging is not imported at startup. So, however os (and friends, there are a lot of modules in sys.modules at startup) is imported, it is different from how readline.so is imported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12238>
_______________________________________

From report at bugs.python.org  Tue Jun  7 15:16:11 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 07 Jun 2011 13:16:11 +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: <1307452571.82.0.930362330458.issue11784@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The patch looks good to me and applies cleanly on top of 3.3 and 2.7.

----------
nosy: +petri.lehtinen
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11784>
_______________________________________

From report at bugs.python.org  Tue Jun  7 15:21:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 07 Jun 2011 13:21:46 +0000
Subject: [issue12274] "Print window" menu on IDLE aborts whole application
In-Reply-To: <1307427367.68.0.910605365077.issue12274@psf.upfronthosting.co.za>
Message-ID: <E1QTwE5-000752-8N@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0aa3064d1cef by ?ukasz Langa in branch '3.2':
#12274: use proper escaping for % in IDLE config.
http://hg.python.org/cpython/rev/0aa3064d1cef

New changeset b410d013e7a8 by ?ukasz Langa in branch 'default':
#12274: use proper escaping for % in IDLE config (merged from 3.2).
http://hg.python.org/cpython/rev/b410d013e7a8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12274>
_______________________________________

From report at bugs.python.org  Tue Jun  7 15:21:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Jun 2011 13:21:54 +0000
Subject: [issue12238] Readline module loading in interactive mode
In-Reply-To: <1307452381.21.0.720000044317.issue12238@psf.upfronthosting.co.za>
Message-ID: <1307452909.3530.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The difference is that logging is not imported at startup. So, however
> os (and friends, there are a lot of modules in sys.modules at startup)
> is imported, it is different from how readline.so is imported.

For the record, os is imported by the _io module:

    /* put os in the module state */
    state->os_module = PyImport_ImportModule("os");
    if (state->os_module == NULL)
        goto fail;

(in Modules/_io/_iomodule.c)

This probably happens before sys.path is
adjusted/tweaked/fixed/garbled/whatever.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12238>
_______________________________________

From report at bugs.python.org  Tue Jun  7 15:26:42 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 07 Jun 2011 13:26:42 +0000
Subject: [issue12274] "Print window" menu on IDLE aborts whole application
In-Reply-To: <1307427367.68.0.910605365077.issue12274@psf.upfronthosting.co.za>
Message-ID: <1307453202.14.0.876494171433.issue12274@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

In 3.2 configparser started validating syntax in interpolation-aware parsers by default. I fixed the configuration.

It's unfortunate this configuration error hasn't been caught before in testing. We need a unit test for broken configuration and a change in IDLE so that it doesn't silently crash when configuration is invalid.

----------
nosy: +kbk
stage:  -> test needed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12274>
_______________________________________

From report at bugs.python.org  Tue Jun  7 15:28:33 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 07 Jun 2011 13:28:33 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1307453313.16.0.118228474596.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I should have specified - the patch is for 3.2. 2.7 code in this area is different but I'll get to that, and default/3.3 will also get this patch but it'll probably require some tweaking.

I guess I went overboard on the refactoring which is why Victor is seeing errors and has the issues with Unicode related stuff. I'll have to put back in the narrow version of the win32_xstat_impl function for now. I'm not comfortable messing with something new and fancy this late in the cycle so I'll just go back to a structure that worked and figure out something better later on.


I'd rather figure out the test_rmdir_on_directory_link_to_missing_target stuff on another issue - this issue has already held up the release long enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Tue Jun  7 15:51:34 2011
From: report at bugs.python.org (Jesse Litton)
Date: Tue, 07 Jun 2011 13:51:34 +0000
Subject: [issue12262] Not Inheriting File Descriptors on Windows?
In-Reply-To: <1307133348.7.0.486629796214.issue12262@psf.upfronthosting.co.za>
Message-ID: <1307454694.58.0.638142926833.issue12262@psf.upfronthosting.co.za>


Jesse Litton <3vi1jl at gmail.com> added the comment:

Yes, socat was compiled under cygwin.  I'll have to investigate whether I want to go the route of cygwin separately or just just leave the script as a pure stdin/out filter (since neither I nor the users have the cygwin environment installed).

After reading what you said, I re-read the MS notes (http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx?mfr=true) and finally noticed the 'specific to each tool' text next to the description for handles 3-9.
 
Just to be sure, I came up with this simple test:

   echo test 1>&3 | set /P TEST= 0<&3

Which basically squashes my misconception, as it doesn't work.

So, I believe now that what I wanted is beyond the capabilities of the common Windows command shell, and this can be closed/invalid as not being a Python issue.  I also wish I was home using my Linux box about now.  :)

Thank you all very much for taking the time to help educate me on this!

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12262>
_______________________________________

From report at bugs.python.org  Tue Jun  7 16:28:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Jun 2011 14:28:12 +0000
Subject: [issue12238] Readline module loading in interactive mode
In-Reply-To: <1307015860.03.0.129842780518.issue12238@psf.upfronthosting.co.za>
Message-ID: <1307456892.94.0.825655502428.issue12238@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yeah, that would be my guess.  And readline.so is imported in main at a point where it has decided we are going into interactive mode, which is presumably after all other initialization has taken place, including the path munging.

Thus my suggestion that that particular import of readline.so should be special cased...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12238>
_______________________________________

From report at bugs.python.org  Tue Jun  7 16:41:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 14:41:52 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1307457712.95.0.0361463451474.issue12242@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>> What would the value be for non-C Python implementations?

> I'm not really sure how this idea could have any value for those
> implementations, at least for the ones that can't make use of C
> extensions at all

The question was about the meaning of a new ?compiler? environment marker.  Would it be set to the empty string in Jython?  Not available?  Or do you think that there is no issue, since Jython would not try to compiler C files?

> I'm not entirely sure how common this is; even within those people
> who write C extensions, but I'm pretty sure some problems are
> unavoidable, such as compiler-specific options when linking to
> external libraries or compiler-specific ways of specifying
> compatibility options.

The SO page contains some pretty crude hacks.

Instead of putting more things into the PEP 345 environment markers, why not extend the extra_compile_args field to take a dictionary mapping regexes to match compiler names and versions to arguments?

In code:

Extension(..., extra_compile_args={'gcc': '-fo',
                                   'gcc .* 4.2': '-foo'})

In setup.cfg:

[build_ext] (or maybe extensions section)
extra_args =
  gcc = -fo
  gcc .* 4.2 = -foo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12242>
_______________________________________

From report at bugs.python.org  Tue Jun  7 16:52:09 2011
From: report at bugs.python.org (Derek Wilson)
Date: Tue, 07 Jun 2011 14:52:09 +0000
Subject: [issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
In-Reply-To: <1242668944.28.0.292370665479.issue6056@psf.upfronthosting.co.za>
Message-ID: <1307458329.6.0.874142127521.issue6056@psf.upfronthosting.co.za>


Derek Wilson <jderekwilson at gmail.com> added the comment:

This should be higher priority as one of the major benefits of the multiprocessing module is remote process management in a completely transparent manner. socket timeouts are very important in this context as blocking forever waiting for a connection is not always an option. 

The problem of not being able to use a default socket timeout for other purposes in combination with multiprocessing managers is definitely an issue, but making multiprocessing actually use the timeout itself if set would be a huge advantage.

This might not be the place to ask for it, but it would make sense for manager objects to gain a timeout attribute to be used as a timeout for local or remote communications. At the very least, the manager.connect() method should accept a timeout argument.

----------
nosy: +Derek.Wilson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6056>
_______________________________________

From report at bugs.python.org  Tue Jun  7 17:07:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 15:07:17 +0000
Subject: [issue12019] Dead or buggy code in importlib.test.__main__
In-Reply-To: <1304698107.84.0.876175210451.issue12019@psf.upfronthosting.co.za>
Message-ID: <1307459237.94.0.687327531544.issue12019@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Brett: Merging is hardly a hassle for me, nor would it take any time in this case (non-conflicting changes are applied by Mercurial itself).  I handle merges in projects that use multiple repositories, tons of clones, translation branches, so I?m a merge master :)

Georg: Thanks for confirming it?s not okay, I got confused for a bit about general Python policy vs. stricter distutils policy.  (I asked because I had set the 3.2 and 3.3 versions and Brett did not change them.)

----------
status: open -> pending
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12019>
_______________________________________

From report at bugs.python.org  Tue Jun  7 17:07:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 15:07:55 +0000
Subject: [issue9302] distutils API Reference: setup() and Extension
	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1307459275.62.0.737210921023.issue9302@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sorry, I thought updating the status was enough to convey ?I?m about to commit this?.

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9302>
_______________________________________

From report at bugs.python.org  Tue Jun  7 17:12:04 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 07 Jun 2011 15:12:04 +0000
Subject: [issue12019] Dead or buggy code in importlib.test.__main__
In-Reply-To: <1304698107.84.0.876175210451.issue12019@psf.upfronthosting.co.za>
Message-ID: <1307459524.86.0.326591818368.issue12019@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't think our policy is that strict, i.e. I wouldn't revert the change if it was already committed.  But it's a bit slippery, and I'd rather have no behavior-changing "cleanups" end up in 3.2 originating in good intentions.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12019>
_______________________________________

From report at bugs.python.org  Tue Jun  7 17:13:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 15:13:07 +0000
Subject: [issue12019] Dead or buggy code in importlib.test.__main__
In-Reply-To: <1304698107.84.0.876175210451.issue12019@psf.upfronthosting.co.za>
Message-ID: <1307459587.38.0.217951676191.issue12019@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agreed; I didn?t mean to imply that strict was restrictive, but that it was safe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12019>
_______________________________________

From report at bugs.python.org  Tue Jun  7 17:14:30 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Jun 2011 15:14:30 +0000
Subject: [issue9302] distutils API Reference: setup() and Extension
	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1307459670.25.0.86715827466.issue9302@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Um, no.

'pending' is 'pending close', specifically meaning, 'this issue is going to be closed (with a rejected status of some sort) unless someone objects or provides more information.'

Someday, pending issues will be autoclosed after N days.  Quite possibly this summer, since Ezio is working on roundup this summer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9302>
_______________________________________

From report at bugs.python.org  Tue Jun  7 17:32:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 07 Jun 2011 15:32:01 +0000
Subject: [issue11041] On the distutils2 documentation,
	'requires-python' shouldn't be documented as *multi
In-Reply-To: <1296214788.72.0.049703794101.issue11041@psf.upfronthosting.co.za>
Message-ID: <E1QTyG8-0002CG-KR@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d8d1bd2c4847 by ?ric Araujo in branch 'default':
Fix documentation of requires-python field in setup.cfg (#11041)
http://hg.python.org/cpython/rev/d8d1bd2c4847

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11041>
_______________________________________

From report at bugs.python.org  Tue Jun  7 17:32:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 07 Jun 2011 15:32:02 +0000
Subject: [issue11092] Setup.cfg isn't packaged when running sdist
In-Reply-To: <1296582156.21.0.82325099923.issue11092@psf.upfronthosting.co.za>
Message-ID: <E1QTyG8-0002CG-KK@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5940d2d82dee by ?ric Araujo in branch 'default':
Fix sdist to always include setup.cfg (#11092), to comply with the spec
http://hg.python.org/cpython/rev/5940d2d82dee

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11092>
_______________________________________

From report at bugs.python.org  Tue Jun  7 17:35:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 15:35:25 +0000
Subject: [issue9302] distutils API Reference: setup() and Extension
	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1307460925.9.0.450498616603.issue9302@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Oh, thanks for clearing a misunderstanding I?ve had for a year!  I was using the pending status to prioritize issues (I have a personal ?assigned to me + pending? query, now I?ll use priority instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9302>
_______________________________________

From report at bugs.python.org  Tue Jun  7 17:35:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 15:35:56 +0000
Subject: [issue9302] distutils API Reference: setup() and Extension
	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1307460956.86.0.970305311009.issue9302@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This also explains why any new message cancels the pending status, BTW.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9302>
_______________________________________

From report at bugs.python.org  Tue Jun  7 17:38:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 15:38:34 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1307461114.19.0.641070505567.issue6884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m sorry I couldn?t fix this one in 3.1.  I didn?t take the time to download and install a Windows to test this year, and right now I don?t have the bandwidth.  I?ll get to it as soon as possible.

----------
status: pending -> open
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Tue Jun  7 17:38:44 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 07 Jun 2011 15:38:44 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1307461124.33.0.470417228604.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Victor - does the new patch pass all tests for you on 3.2?

----------
Added file: http://bugs.python.org/file22274/issue12084_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Tue Jun  7 17:48:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 15:48:53 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1307461733.49.0.987510653631.issue12279@psf.upfronthosting.co.za>
Message-ID: <1307461733.49.0.987510653631.issue12279@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

In the current packaging module, the PEP 376 .dist-info directory is generated at install time.  It should be split into two phases, build_distinfo and install_distinfo, to support at least two use cases:

- the develop command, which needs access to .dist-info
- the resources API (packaging.database.get_file), which is intended to work from an uninstalled codebase too.

The normal directory to put the generated files would be the build directory; however, setuptools? egg_info command generates the file in the same directory as the setup.py file.  I?d prefer we avoid it in packaging, for consistency with other build_* commands, and to avoid that every project has to put ?*.dist-info? in their VCS ignore file, but I don?t know if there is a technical reason that constrains setuptools to do so.

----------
assignee: eric.araujo
components: Distutils2
keywords: gsoc
messages: 137842
nosy: alexis, eric.araujo, higery
priority: normal
severity: normal
stage: needs patch
status: open
title: Add build_distinfo command to packaging
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Tue Jun  7 17:54:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 15:54:54 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1307462094.64.0.775543640935.issue8668@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FTR, Xu Dehai (higery) is working on this for GSoC.  We discussed the requirements on the mailing list: http://groups.google.com/group/the-fellowship-of-the-packaging/browse_thread/thread/ae196efc4956b9e2
This message in particular defines clearly the requirements: http://groups.google.com/group/the-fellowship-of-the-packaging/msg/9ef937cf2a90a882

----------
dependencies: +Add build_distinfo command to packaging
nosy: +higery
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Tue Jun  7 17:55:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 15:55:35 +0000
Subject: [issue11041] On the distutils2 documentation,
	'requires-python' shouldn't be documented as *multi
In-Reply-To: <1296214788.72.0.049703794101.issue11041@psf.upfronthosting.co.za>
Message-ID: <1307462135.09.0.251232767942.issue11041@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> eric.araujo
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11041>
_______________________________________

From report at bugs.python.org  Tue Jun  7 17:56:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 15:56:43 +0000
Subject: [issue11092] setup.cfg isn't packaged when running sdist
In-Reply-To: <1296582156.21.0.82325099923.issue11092@psf.upfronthosting.co.za>
Message-ID: <1307462203.95.0.649073938878.issue11092@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is now fixed.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
title: Setup.cfg isn't packaged when running sdist -> setup.cfg isn't packaged when running sdist
type:  -> behavior
versions: +Python 3.3 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11092>
_______________________________________

From report at bugs.python.org  Tue Jun  7 18:00:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 16:00:50 +0000
Subject: [issue7826] support caching for 2to3
In-Reply-To: <1264985952.93.0.779639488883.issue7826@psf.upfronthosting.co.za>
Message-ID: <1307462450.39.0.361123771776.issue7826@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FTR: https://github.com/pv/lib2to3cache

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7826>
_______________________________________

From report at bugs.python.org  Tue Jun  7 18:04:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 07 Jun 2011 16:04:20 +0000
Subject: [issue12019] Dead or buggy code in importlib.test.__main__
In-Reply-To: <1304698107.84.0.876175210451.issue12019@psf.upfronthosting.co.za>
Message-ID: <E1QTylO-0005D1-Nb@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5392be94ea65 by ?ric Araujo in branch 'default':
Kill dead code in importlib.test.__main__ (#12019, reviewed by Brett Cannon)
http://hg.python.org/cpython/rev/5392be94ea65

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12019>
_______________________________________

From report at bugs.python.org  Tue Jun  7 18:07:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 16:07:09 +0000
Subject: [issue8927] Handle version incompatibilities in dependencies
In-Reply-To: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>
Message-ID: <1307462829.37.0.747645848436.issue8927@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

As discussed on the Fellowship ML, ActiveState has implemented an algo for a smart dependency graph: https://github.com/ActiveState/depgraph

On the one hand, I think it?s not outside the scope of packaging.depgraph to be a bit smarter about dependencies.  On the other hand, this is still a deep research subject that?s by no means solved, so maybe keeping depgraph simple and dumb is more maintainable.

----------
nosy: +srid
versions: +Python 3.3 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8927>
_______________________________________

From report at bugs.python.org  Tue Jun  7 18:08:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 16:08:18 +0000
Subject: [issue12019] Dead or buggy code in importlib.test.__main__
In-Reply-To: <1304698107.84.0.876175210451.issue12019@psf.upfronthosting.co.za>
Message-ID: <1307462898.0.0.615030517904.issue12019@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I checked the patch again with ./python -m importlib.test and ./python Lib/importlib/test and committed.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12019>
_______________________________________

From report at bugs.python.org  Tue Jun  7 18:35:30 2011
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 07 Jun 2011 16:35:30 +0000
Subject: [issue8927] Handle version incompatibilities in dependencies
In-Reply-To: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>
Message-ID: <1307464530.69.0.486693642014.issue8927@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

The only way to fix this is to /not/ install *any* packages prior to resolving *all* dependencies ... which means that there needs to be a way to resolve the entire dependency graph for any given package in PyPI.

If PyPI provided a mechanism to fetch the entire dependency graph[1], then https://github.com/ActiveState/depgraph can be used to implement comprehensive dependency resolution. PyPM can do this because the PyPM repository provides a sqlite db containing dependency information for all packages and their versions.

Let me know if you need any assistance regarding ActiveState's depgraph implementation (I may have pending commits to be merged to the GitHub repo)

[1] I posted a few suggestions in regards to facilitating such exposure of static metadata in PyPI to distutils-sig@ - but until this day they remain as merely ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8927>
_______________________________________

From report at bugs.python.org  Tue Jun  7 18:48:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 16:48:58 +0000
Subject: [issue8927] Handle version incompatibilities in dependencies
In-Reply-To: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>
Message-ID: <1307465338.65.0.0419680452556.issue8927@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The only way to fix this is to /not/ install *any* packages prior to
> resolving *all* dependencies

packaging.install rolls back in case of error, so the system can?t be left in a half-installed state.  p7g.install is only as smart as p7g.depgraph, however.

> which means that there needs to be a way to resolve the entire
> dependency graph for any given package in PyPI.

PyPI exposes requires, obsoletes and provides for releases that upload PEP 345 metadata; client code using p7g.pypi and p7g.depgraph can then build a dependency graph.

> the PyPM repository provides a sqlite db containing dependency
> information for all packages and their versions.

This experiment with a local copy of the full repo graph is interesting.  Do you have blog posts or something talking about synchronization issues, dealing with multiple repositories, using SQL vs. something less ugly <wink>, etc.?

> Let me know if you need any assistance regarding ActiveState's
> depgraph implementation

First, what we need here is a pronouncement from Tarek about smarter depgraph vs. simple stupid depgraph.  If we decide to improve depgraph, ideas from your code will have to be extracted and ported.  This will probably require a contributor agreement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8927>
_______________________________________

From report at bugs.python.org  Tue Jun  7 18:50:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 16:50:23 +0000
Subject: [issue12273] Change ast.__version__ calculation	to provide consistent
	ordering
In-Reply-To: <1307419934.4.0.45216742345.issue12273@psf.upfronthosting.co.za>
Message-ID: <1307465423.13.0.879457238213.issue12273@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/issue12273>
_______________________________________

From report at bugs.python.org  Tue Jun  7 18:54:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 16:54:03 +0000
Subject: [issue12278] Core mentorship mention in the devguide
In-Reply-To: <1307445407.08.0.276007268612.issue12278@psf.upfronthosting.co.za>
Message-ID: <1307465643.92.0.948566674335.issue12278@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  I think it should be rewritten a bit:
> If you are interested in improving Python and contributing to its development,
> `Python Mentors`_ are here to help you.

python-ideas and python-dev are open to new people interested in contributing, not only python-mentors; the specificity of the latter is that it is intended as very user friendly.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12278>
_______________________________________

From report at bugs.python.org  Tue Jun  7 18:56:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 16:56:35 +0000
Subject: [issue11203] gzip doc is behind
In-Reply-To: <1297539632.81.0.320134391105.issue11203@psf.upfronthosting.co.za>
Message-ID: <1307465795.4.0.299695603109.issue11203@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> This implies that it also supports close().
One has to follow the link to BufferedIOBase and then to IOBase, but I think it?s okay.

Richard: Does that address your issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11203>
_______________________________________

From report at bugs.python.org  Tue Jun  7 18:59:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 16:59:32 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1307465972.26.0.0463219779716.issue12277@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have included this in a patch I?m preparing to fix several typos at once.

----------
assignee: docs at python -> eric.araujo
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12277>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:00:35 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 07 Jun 2011 17:00:35 +0000
Subject: [issue12273] Change ast.__version__ calculation	to provide consistent
	ordering
In-Reply-To: <1307419934.4.0.45216742345.issue12273@psf.upfronthosting.co.za>
Message-ID: <1307466035.71.0.777479555541.issue12273@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I propose we leave ast.__version__ alone. Using ast.__version__ at all should be a very advanced usecase. Generally, you should just be able to look at sys.version_info. We could document this rather than duplicating sys.version_info in ast.__version__. I think ast.__version__ is mostly useful for things like:

print("Running with Python {} and AST {}".format(sys.mercurial[2], ast.__version__)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12273>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:02:44 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 07 Jun 2011 17:02:44 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1307386776.33.0.623021006981.issue9205@psf.upfronthosting.co.za>
Message-ID: <BANLkTinodCWcJhEGskAkAM6UUY7zHVQe=Q@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Ok, the dependencies are now committed. Here is a new patch addressing Charles-Fran?ois' comments: select() is now called before each call to read() when sentinels are given, to avoid race conditions.

The patch looks fine to me (but I didn't look at win32-specific code).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:03:44 2011
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 07 Jun 2011 17:03:44 +0000
Subject: [issue8927] Handle version incompatibilities in dependencies
In-Reply-To: <1307465338.65.0.0419680452556.issue8927@psf.upfronthosting.co.za>
Message-ID: <A978CFBC-5308-4F4A-BF79-6F780D2A8D4F@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On 2011-06-07, at 9:48 AM, ?ric Araujo wrote:

> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
>> The only way to fix this is to /not/ install *any* packages prior to
>> resolving *all* dependencies
> 
> packaging.install rolls back in case of error, so the system can?t be left in a half-installed state.  p7g.install is only as smart as p7g.depgraph, however.

Well, if the same behavior is adopted for dependency conflicts (eg: see issue description) as well, it would necessitate rolling back by uninstalling the previous N packages, then installing these N packages (again) by traversing a different path (and repeat for other conflicts), would it not?

>> which means that there needs to be a way to resolve the entire
>> dependency graph for any given package in PyPI.
> 
> PyPI exposes requires, obsoletes and provides for releases that upload PEP 345 metadata; client code using p7g.pypi and p7g.depgraph can then build a dependency graph.

Not all packages upload their release sources (thus metadata) to PyPI, which is why - I believe - PIP is scraping the Simple Index and home_page urls to get the appropriate sdist for any package. I am not fully aware of what kind of packages p7g.install is supposed to support, though. I assume that setuptools-style projects (using install_requires) are not supported by p7g.install.

>> the PyPM repository provides a sqlite db containing dependency
>> information for all packages and their versions.
> 
> This experiment with a local copy of the full repo graph is interesting.  Do you have blog posts or something talking about synchronization issues, dealing with multiple repositories, using SQL vs. something less ugly <wink>, etc.?

The local index cache is automatically updated not more than once a day. Multiple repositories are searched in the configured order (linearly). SQL is just a data format, the remote index can be of any format (xml, json, pickle, ..) as long as the client can easily query the dependency chain.

But its probably much simpler to only expose per-package dependency (and other metadata) through REST urls (at the cost of network delays, however). No index is required. Eg:

    http://pypi.python.org/metadata/scipy/0.9.0/DIST-INFO -> requires, obsoletes, etc...

(of course, this assumes that even packages that do not upload their sdists have the metadata available in PyPI somehow; perhaps the server caches them. we have our own pypi-like mirror that does this)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8927>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:07:30 2011
From: report at bugs.python.org (K Richard Pixley)
Date: Tue, 07 Jun 2011 17:07:30 +0000
Subject: [issue11203] gzip doc is behind
In-Reply-To: <1297539632.81.0.320134391105.issue11203@psf.upfronthosting.co.za>
Message-ID: <1307466450.81.0.616603024277.issue11203@psf.upfronthosting.co.za>


K Richard Pixley <rich at noir.com> added the comment:

My point was for python-2.7.  I haven't stumbled into the buffer protocol yet.  So no, it doesn't really.

I still think the documentation, especially the 2.7 doc, could be more explicit.

My concern here is with the use of close() becoming obscure, a second class citizen, or an afterthought.  While I greatly appreciate the context manager, there are times when I want an enduring open channel for which the context manager just isn't appropriate.  Even in a world with context manager, open and close need to be available and presented as a pair.

It isn't clear to me from reading the doc or looking at the examples that gzip is expected to support a close call.  Yes, I concur that there is an implication, but I would prefer to see it stated explicitly along with the explicit statement that it supports an open call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11203>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:08:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 17:08:58 +0000
Subject: [issue8927] Handle version incompatibilities in dependencies
In-Reply-To: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>
Message-ID: <1307466538.98.0.735640970823.issue8927@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Tarek?s reply on IRC:

> I think we should make it dumb: in case of a conflict, it's always
> better/simpler to let the user deal with it.  A simple "could not
> install because you have package X version Y installed'.  Trying to do
> something smarter is very very hard and will probably fail.

About adding smarts to deal with simple cases like the one you mentioned in your email:
> If we provide automation for simple cases, people will want more.

So I think we?re leaning towards rejecting this.  pysetup is a simple installer for simple installs; pip and other installers will use the information returned by packaging.depgraph/install to be smart about conflicts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8927>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:11:52 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 07 Jun 2011 17:11:52 +0000
Subject: [issue6474] Inconsistent TypeError message on function calls with
	wrong number of arguments
In-Reply-To: <1247495805.32.0.528519491274.issue6474@psf.upfronthosting.co.za>
Message-ID: <1307466712.45.0.180677860348.issue6474@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Hopefully this situation was improved by #12265.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6474>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:14:05 2011
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 07 Jun 2011 17:14:05 +0000
Subject: [issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
In-Reply-To: <1242668944.28.0.292370665479.issue6056@psf.upfronthosting.co.za>
Message-ID: <1307466845.04.0.751973237046.issue6056@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I agree derek, I think that would be a fine addition, however we lack a patch and I don't have the current bandwidth to add it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6056>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:19:40 2011
From: report at bugs.python.org (Jonas H.)
Date: Tue, 07 Jun 2011 17:19:40 +0000
Subject: [issue11975] Fix referencing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1307467180.35.0.336901963074.issue11975@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

Having one page with two objects of the same name, e.g.

  .. function:: foo

  .. class:: foo

renders to two entries with the same anchor name (#foo). The first entry gets a link-to-this-paragraph marker, the second one doesn't.

Internal references (from within the same document) always link to the first entry because they use #foo anchor. (So if you put the class directive first, all links go to the class anchor.)

The first external reference (using intersphinx) always goes to the first target document element - no matter which type both have. The second reference isn't turned into a hyperlink.

This behaviour seems consistent with how HTML anchors work.

Having the two objects on two different pages however shows slightly odd results. Say we have this code on page 1:

  .. class:: foo

  :class:`foo`
  :func:`foo`

and

  .. function:: foo

on page 2, then both links in page 1 go to the page 1 'foo' (the class). However if you change order (putting the func role before the class role), those links go to the page 2 'foo' (the function).

All intersphinx-ed links go to the object on page 1, no matter the role order on page 1 or the external page.


I think we can conclude that using class and function directives at the same time doesn't help very much...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:20:01 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Tue, 07 Jun 2011 17:20:01 +0000
Subject: [issue12278] Core mentorship mention in the devguide
In-Reply-To: <1307445407.08.0.276007268612.issue12278@psf.upfronthosting.co.za>
Message-ID: <1307467201.25.0.587260338502.issue12278@psf.upfronthosting.co.za>


Adam Woodbeck <adam.woodbeck at gmail.com> added the comment:

?ric, good point.  I'll propose different wording when I have an opportunity later today.  In the mean time, I'm certainly open to suggestions, especially as I get my feet wet.

So you would also prefer a mention of the python-ideas and python-dev mailing lists, where the former is primarily for suggesting new development ideas, and the latter is for core language discussion.  Correct?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12278>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:25:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 17:25:53 +0000
Subject: [issue11203] gzip doc is behind
In-Reply-To: <1297539632.81.0.320134391105.issue11203@psf.upfronthosting.co.za>
Message-ID: <1307467553.29.0.778072772368.issue11203@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

In 2.7, while there is no index-generating entry for the close method, it is mentioned: ?Calling a GzipFile object?s close() method [...]?.

> Yes, I concur that there is an implication, but I would prefer to see
> it stated explicitly along with the explicit statement that it
> supports an open call.

I wouldn?t like to see the docs for int, float, complex, Decimal, Fraction, GzipFile, BZ2File, BytesIO, StringIO and all others having duplicated lists of methods and attributes that are already documented in the doc of the ABC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11203>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:29:34 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Tue, 07 Jun 2011 17:29:34 +0000
Subject: [issue6474] Inconsistent TypeError message on function calls with
	wrong number of arguments
In-Reply-To: <1247495805.32.0.528519491274.issue6474@psf.upfronthosting.co.za>
Message-ID: <1307467774.9.0.164523679917.issue6474@psf.upfronthosting.co.za>


Oleg Oshmyan <chortos at inbox.lv> added the comment:

Unfortunately it was not.

>>> Extension('myext', define_macros=[])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() takes from 3 to 17 positional arguments but 3 were given

The issue is that the message tries to differentiate between positional and keyword arguments, while it really should differentiate between required and optional ones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6474>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:38:56 2011
From: report at bugs.python.org (K Richard Pixley)
Date: Tue, 07 Jun 2011 17:38:56 +0000
Subject: [issue11203] gzip doc is behind
In-Reply-To: <1297539632.81.0.320134391105.issue11203@psf.upfronthosting.co.za>
Message-ID: <1307468336.67.0.0377935913221.issue11203@psf.upfronthosting.co.za>


K Richard Pixley <rich at noir.com> added the comment:

An interesting point, although I think that's only relevant if the documentation lists the ABC and a reference to it.  (python-3 doc essentially does this.)

I see no such reference in the 2.7 gzipfile doc, which leads me to believe, (from the doc alone), that it's an independent implementation of a "file like object".

This may not be important enough to even merit the time we've already put into it.  Please feel free to close this ticket without change if you prefer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11203>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:39:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 17:39:56 +0000
Subject: [issue8927] Handle version incompatibilities in dependencies
In-Reply-To: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>
Message-ID: <1307468396.15.0.324396170806.issue8927@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Not all packages upload their release sources (thus metadata) to PyPI
No, it?s register that uploads metadata.

> which is why - I believe - PIP is scraping the Simple Index and
> home_page urls to get the appropriate sdist for any package.
Yes, the screen scraping in setuptools comes from the fact that not all projects upload distributions on PyPI.  (Actually, setuptools did the screen scraping before PyPI supported distributions upload.)

> I am not fully aware of what kind of packages p7g.install is supposed
> to support, though. I assume that setuptools-style projects (using
> install_requires) are not supported by p7g.install.
I think they are, or if not it?s a missing feature we want to support.  Kelsey and Alexis know more about that topic.  See recent threads on Fellowship.

> But its probably much simpler to only expose per-package dependency
> (and other metadata) through REST urls
RESTful PyPI is Alexis? pony :)  Right know, the XML-RPC exposes the metadata, including PEP 345 Requires-Dist if the release provided it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8927>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:41:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 17:41:48 +0000
Subject: [issue11203] gzip doc is behind
In-Reply-To: <1297539632.81.0.320134391105.issue11203@psf.upfronthosting.co.za>
Message-ID: <1307468508.27.0.101614050106.issue11203@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I see no such reference in the 2.7 gzipfile doc

Did you miss the first part of my previous message?  The 2.7 docs for GzipFile do not link to the ABC, but they mention the close method in plain text.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11203>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:43:39 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 07 Jun 2011 17:43:39 +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: <1307468619.94.0.757287865085.issue11277@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the update.  Since the fix will be in a future version of OS X 10.7 Lion, and which has not been released yet, so it is not appropriate to change mmap until there has been an opportunity to test it.  But even then, we would need to be careful about adding a compile-time test as OS X binaries are often built to be compatible for a range of operating system version so avoid adding compilation conditionals unless really necessary.  If after 10.7 is released and someone is able to test that it works as expected, the standard way to support it would be to use the Apple-supplied availability macros to test for the minimum supported OS level of the build assuming it makes enough of a performance difference to bother to do so: http://developer.apple.com/library/mac/#technotes/tn2064/_index.html

(Modules/_ctypes/darwin/dlfcn_simple.c is one of the few that has this kind of test.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:46:59 2011
From: report at bugs.python.org (K Richard Pixley)
Date: Tue, 07 Jun 2011 17:46:59 +0000
Subject: [issue11203] gzip doc is behind
In-Reply-To: <1297539632.81.0.320134391105.issue11203@psf.upfronthosting.co.za>
Message-ID: <1307468819.62.0.218822416969.issue11203@psf.upfronthosting.co.za>


K Richard Pixley <rich at noir.com> added the comment:

I didn't miss it.

I think the close call needs equal treatment to the open call.  The mention is certainly present, but seems implicit to me.  I would prefer to see it listed explicitly.

But I also don't think it's important enough in the 2.7 docs to discuss it much further.  You've convinced me that it's not worth fixing.  Let's drop it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11203>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:47:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 17:47:03 +0000
Subject: [issue11595] Miscellaneous bugs in cfg_to_args() utility function
In-Reply-To: <1300466317.84.0.72161184259.issue11595@psf.upfronthosting.co.za>
Message-ID: <1307468823.82.0.613229644994.issue11595@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you refresh your patch for packaging?

----------
assignee: tarek -> eric.araujo
stage:  -> patch review
type:  -> behavior
versions: +Python 3.3 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11595>
_______________________________________

From report at bugs.python.org  Tue Jun  7 19:47:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Jun 2011 17:47:59 +0000
Subject: [issue11200] Addition of abiflags breaks distutils
In-Reply-To: <1297535287.04.0.13129153677.issue11200@psf.upfronthosting.co.za>
Message-ID: <1307468879.33.0.164513973956.issue11200@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Now fixed in packaging too.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11200>
_______________________________________

From report at bugs.python.org  Tue Jun  7 20:01:58 2011
From: report at bugs.python.org (Dave Abrahams)
Date: Tue, 07 Jun 2011 18:01:58 +0000
Subject: [issue8927] Handle version incompatibilities in dependencies
In-Reply-To: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>
Message-ID: <1307469718.49.0.764340019294.issue8927@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

I'm sorry, but it is simply not true that this is not a solved problem.  This is a well-understood problem that's solved --- at least as well as anyone could want it to be --- by aptitude (not apt-get) and by http://en.opensuse.org/openSUSE:Libzypp_satsolver

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8927>
_______________________________________

From report at bugs.python.org  Tue Jun  7 20:03:55 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 07 Jun 2011 18:03:55 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <1307469835.94.0.686483406329.issue12021@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

It seems I did. Attached now for real :)

----------
Added file: http://bugs.python.org/file22275/mmap_read_all_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12021>
_______________________________________

From report at bugs.python.org  Tue Jun  7 20:05:07 2011
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 07 Jun 2011 18:05:07 +0000
Subject: [issue8927] Handle version incompatibilities in dependencies
In-Reply-To: <1307468396.15.0.324396170806.issue8927@psf.upfronthosting.co.za>
Message-ID: <9B254601-5124-4190-9AEA-00D04D06559C@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On 2011-06-07, at 10:39 AM, ?ric Araujo wrote:

> ?ric Araujo <merwok at netwok.org> added the comment:
> 
>> Not all packages upload their release sources (thus metadata) to PyPI
> No, it?s register that uploads metadata.

(was not sent before?)

Ok, that's interesting. Does p7g.install support packages that do not register their new releases?

Setuptools/PIP does by scraping the project home pages.

Eg: http://pypi.python.org/pypi/PyChecker incorrectly (but expected) shows 0.8.12 as latest, but http://pychecker.sourceforge.net/ shows 0.8.19 as the latest. Will p7g.install install 0.8.19?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8927>
_______________________________________

From report at bugs.python.org  Tue Jun  7 20:08:00 2011
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 07 Jun 2011 18:08:00 +0000
Subject: [issue8927] Handle version incompatibilities in dependencies
In-Reply-To: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>
Message-ID: <1307470080.13.0.0854545628574.issue8927@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Dave, but aptitude contains a local index of all dependency information. Whereas, PyPI's infrastructure and pip/easy_install/p7g.install do not rely on one. Therefore, I think when Tarek said "Trying to do something smarter is very very hard and will probably fail." he is referring to doing such dependency resolution *with* the constraint of lack of such local metadata index.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8927>
_______________________________________

From report at bugs.python.org  Tue Jun  7 20:36:11 2011
From: report at bugs.python.org (Eli Collins)
Date: Tue, 07 Jun 2011 18:36:11 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1307471771.01.0.768334610317.issue12242@psf.upfronthosting.co.za>


Eli Collins <elic at assurancetechnologies.com> added the comment:

> The question was about the meaning of a new ?compiler? environment
> marker.  Would it be set to the empty string in Jython?  Not available?
>  Or do you think that there is no issue, since Jython would not try to
> compiler C files?

Ah, my bad. I _had_ misunderstood your question. Those cases would definitely need to have more properly defined behavior. As well, my attempt at my original idea convinced me that it may be difficult/impossible to implement an environment marker whose value may depend on per-command options. All told, I think your dict idea is probably a much better route to take (and more powerful to boot). 

I'll try to work up a patch implementing something along the lines you suggested. One issue is that multiple compiler patterns may match, so it might be better to use a list instead of a dict... and since extra_compile_args is already a list, it might be cleaner (and break less existing code) if I implemented a new argument entirely, eg "specific_compile_args" / "specific_link_args"; which took [ (pattern, option_str) ... ], and used the first pattern that matches (if any).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12242>
_______________________________________

From report at bugs.python.org  Tue Jun  7 20:54:25 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 07 Jun 2011 18:54:25 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <4DE965CA.6090306@v.loewis.de>
Message-ID: <BANLkTinLfBT0E_Q5o7vOb2aA54v=CkOsdQ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Jun 3, 2011 at 6:52 PM, Martin v. L?wis <report at bugs.python.org> wrote:
..
>> One reason is the desire to avoid loading Python module from a
>> C-module.
>
> This desire is indeed no guidance for Python development; the opposite
> is the case.

Can you elaborate on this?  I did notice the current trend of mixing
software layers and welcoming circular dependencies in Python stdlib,
but I am not sure this is a good thing.  In the good old times imports
inside functions where frowned upon.  (And for many good reasons.)
Imports from inside C functions seem to be even worse.  Tricks like
this greatly reduce understandability of the code.  The import
statements at the top of the module tell a great deal about what the
module can and cannot do.  When modules can be imported at will as a
side-effect of innocuous looking functions (time.strptime is my
personal pet peeve), analysis of the programs becomes much more
difficult.

>  The only exception may be bootstrapping issues, which I
> claim are irrelevant in this case.

It is hard to tell without attempting an implementation, but my
intuition is exactly the opposite.  I believe parts of the import
mechanism have been implemented in Python and it seems to me that
os.stat() may need to be available before decimal can be imported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Tue Jun  7 21:09:15 2011
From: report at bugs.python.org (Dave Abrahams)
Date: Tue, 07 Jun 2011 19:09:15 +0000
Subject: [issue8927] Handle version incompatibilities in dependencies
In-Reply-To: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>
Message-ID: <1307473755.81.0.869905232431.issue8927@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

That's quite true.  However, I don't think a local index is needed if there's a remote index; you're already looking in a remote index, albeit a less-completeone.  And it could be maintained automatically from individual package metadata.  Maybe that's out of scope for this project, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8927>
_______________________________________

From report at bugs.python.org  Tue Jun  7 21:47:20 2011
From: report at bugs.python.org (Erik Bray)
Date: Tue, 07 Jun 2011 19:47:20 +0000
Subject: [issue11595] Miscellaneous bugs in cfg_to_args() utility function
In-Reply-To: <1300466317.84.0.72161184259.issue11595@psf.upfronthosting.co.za>
Message-ID: <1307476040.18.0.212374773011.issue11595@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

Done.  Also added support for multi-valued description-file values.

----------
Added file: http://bugs.python.org/file22276/issue11595-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11595>
_______________________________________

From report at bugs.python.org  Tue Jun  7 21:59:10 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Jun 2011 19:59:10 +0000
Subject: [issue12273] Change ast.__version__ calculation	to provide consistent
	ordering
In-Reply-To: <1307419934.4.0.45216742345.issue12273@psf.upfronthosting.co.za>
Message-ID: <1307476750.16.0.971059917869.issue12273@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think you should just kill ast.__version__ in that case.  There was a discussion on python-dev and packaging about __version__ and PEP 396 was the result.  If you want the VCS info put it somewhere else (like __vcs_version__?).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12273>
_______________________________________

From report at bugs.python.org  Tue Jun  7 21:59:38 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 07 Jun 2011 19:59:38 +0000
Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with
	VC Express
In-Reply-To: <1307394677.32.0.956164686805.issue7511@psf.upfronthosting.co.za>
Message-ID: <20110607195752.GA26939@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Marc-Andre Lemburg <report at bugs.python.org> wrote:
> >> >> Regarding the latest patch: This is not the right approach, since
> >> >> find_vcvarsall() is supposed to return the path to the vcvarsall.bat
> >> >> file and not an architecture specific setup file. It is later
> >> >> called with the arch identifier, which the arch specific setup files
> >> >> don't check or use.
> > > 
> > > The patch does not change anything for Visual Studio Pro. In Visual Studio
> > > Express (+SDK) vcvarsall.bat is broken, so the architecture specific setup
> > > files have to be used (they also work with a superfluous parameter).
> 
> I guess what I wanted to say is that find_vcvarsall() should
> return None for VC Express and code using it should then
> revert to using a new find_vcvars() function, which takes the
> architecture as parameter and returns the path to the correct
> architecture setup file.
> 
> Hacking the support into find_vcvarsall() is not the right
> approach. You have to add this support one level further up.

I agree that it is nicer if find_vcvarsall() actually returns vcvarsall.
The next level though is query_vcvarsall(), so it would still be wrong
to query vcvars64 in that function.

So unless query_vcvarsall() is renamed to something neutral like set_vcvars(),
I'm not sure where to add the support. But I imagine that renaming is out of
the question.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Tue Jun  7 22:05:27 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Jun 2011 20:05:27 +0000
Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with
	VC Express
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1307477127.65.0.337462626055.issue7511@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/issue7511>
_______________________________________

From report at bugs.python.org  Tue Jun  7 22:39:06 2011
From: report at bugs.python.org (Bryce Verdier)
Date: Tue, 07 Jun 2011 20:39:06 +0000
Subject: [issue12243] getpass.getuser works on OSX
In-Reply-To: <1307029704.02.0.858553376312.issue12243@psf.upfronthosting.co.za>
Message-ID: <1307479146.25.0.0621550411807.issue12243@psf.upfronthosting.co.za>


Bryce Verdier <bryceverdier at gmail.com> added the comment:

I like the idea as well. But I'm not sure what is needed in order to help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12243>
_______________________________________

From report at bugs.python.org  Tue Jun  7 23:05:57 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Tue, 07 Jun 2011 21:05:57 +0000
Subject: [issue12265] revamp argument errors
In-Reply-To: <1307240443.69.0.736494632157.issue12265@psf.upfronthosting.co.za>
Message-ID: <1307480757.26.0.0896266018855.issue12265@psf.upfronthosting.co.za>


Changes by Oleg Oshmyan <chortos at inbox.lv>:


----------
nosy: +chortos

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12265>
_______________________________________

From report at bugs.python.org  Tue Jun  7 23:08:52 2011
From: report at bugs.python.org (Matthew Brunt)
Date: Tue, 07 Jun 2011 21:08:52 +0000
Subject: [issue12280] If statement
In-Reply-To: <1307480932.85.0.0272604438661.issue12280@psf.upfronthosting.co.za>
Message-ID: <1307480932.85.0.0272604438661.issue12280@psf.upfronthosting.co.za>


New submission from Matthew Brunt <mbrunt12 at gmail.com>:

i'm very new to python (currently going through a python for beginners book at work to pass the time), and i'm having trouble with an if statement exercise.  basically, i'm creating a very simple password program that displays "Access Granted" if the if statement is true.  the problem i'm having is that no matter what i set the password to, it seems like it's ignoring the if statement.  the code is copied below, and i greatly appreciate any input.

# Granted or Denied
# Demonstrates an else clause

print("Welcome to System Security Inc.")
print("-- where security is our middle name\n")

password = input("Enter your password: ")

if password == "a":
    print("Access Granted")

input("\n\nPress the enter key to exit.")

----------
components: IDLE
messages: 137883
nosy: Matthew.Brunt
priority: normal
severity: normal
status: open
title: If statement
type: performance
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12280>
_______________________________________

From report at bugs.python.org  Tue Jun  7 23:13:24 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 07 Jun 2011 21:13:24 +0000
Subject: [issue12280] If statement
In-Reply-To: <1307480932.85.0.0272604438661.issue12280@psf.upfronthosting.co.za>
Message-ID: <1307481204.36.0.927764062446.issue12280@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

You might want to check out the python-tutor or python-list email lists (see http://mail.python.org/mailman/listinfo). This is a tracker for bug reports or problems with the Python interpreter and standard libraries.

----------
nosy: +brian.curtin
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12280>
_______________________________________

From report at bugs.python.org  Tue Jun  7 23:48:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jun 2011 21:48:05 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Starting at Python 3.2, the MBCS codec uses MultiByteToWideChar() to decode bytes using flags=MB_ERR_INVALID_CHARS by default (strict error handler), flags=0 for the ignore error handler, and raise a ValueError for other error handlers.

The problem is that the meaning of flags=0 changes with the Windows version:

 - ignore undecodable bytes until Windows XP
 - *replace* undecodable bytes for Windows Vista and later

We should accept "replace" error handler with flags=0, at least on Windows Vista and later.

I don't know if we should only accept "ignore" on Windows <= XP and only "error" on Windows >= Vista, or if the difference should be documented.

----------
components: Unicode
messages: 137885
nosy: amaury.forgeotdarc, haypo
priority: normal
severity: normal
status: open
title: bytes.decode('mbcs', 'ignore') does replace undecodable bytes on Windows Vista or later
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Tue Jun  7 23:54:02 2011
From: report at bugs.python.org (K Richard Pixley)
Date: Tue, 07 Jun 2011 21:54:02 +0000
Subject: [issue11203] gzip doc is behind
In-Reply-To: <1297539632.81.0.320134391105.issue11203@psf.upfronthosting.co.za>
Message-ID: <1307483642.74.0.0805736763917.issue11203@psf.upfronthosting.co.za>


K Richard Pixley <rich at noir.com> added the comment:

I'm now convinced this isn't worth fixing in 2.x.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11203>
_______________________________________

From report at bugs.python.org  Wed Jun  8 00:01:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jun 2011 22:01:22 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1307484082.89.0.499387460482.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

MBCS codec was changed by #850997. Martin von Loewis proposed solutions to implement other error handlers in msg19180.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Wed Jun  8 00:02:04 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 07 Jun 2011 22:02:04 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <BANLkTinLfBT0E_Q5o7vOb2aA54v=CkOsdQ@mail.gmail.com>
Message-ID: <4DEE9FDB.3070804@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Can you elaborate on this?

Not on the tracker; this is appropriate on python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Wed Jun  8 00:02:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jun 2011 22:02:38 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1307484158.09.0.539746489135.issue12281@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/issue12281>
_______________________________________

From report at bugs.python.org  Wed Jun  8 00:14:14 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 07 Jun 2011 22:14:14 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1307468619.94.0.757287865085.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110607221322.GA28023@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

@ Ned Deily <report at bugs.python.org> wrote (2011-06-07 19:43+0200):
> Thanks for the update.  Since the fix will be in a future
> version of OS X 10.7 Lion, and which has not been released yet,
> so it is not appropriate to change mmap until there has been an
> opportunity to test it.

It's really working fine.  That i see that day!
(Not that they start to fix the CoreAudio crashes...)

> But even then, we would need to be careful about adding
> a compile-time test as OS X binaries are often built to be
> compatible for a range of operating system version so avoid
> adding compilation conditionals unless really necessary.
> If after 10.7 is released and someone is able to test that it
> works as expected, the standard way to support it would be to
> use the Apple-supplied availability macros to test for the
> minimum supported OS level of the build assuming it makes enough
> of a performance difference to bother to do so

Of course it only moves the delay from before mmap(2) to after
close(2).  Well, i don't know, if hardcoding is not an option,
a dynamic sysctl(2) lookup may do:

    kern.version = Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011

This is obviously not the right one.  :)
--
Ciao, Steffen
sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Wed Jun  8 00:27:48 2011
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 07 Jun 2011 22:27:48 +0000
Subject: [issue12246] Warn when trying to install third-party module from an
	uninstalled checkout
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307485668.09.0.795764775469.issue12246@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


Added file: http://bugs.python.org/file22277/display_warning_with_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12246>
_______________________________________

From report at bugs.python.org  Wed Jun  8 00:28:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 07 Jun 2011 22:28:39 +0000
Subject: [issue11975] Fix referencing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1307485719.9.0.429615651435.issue11975@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

What if in the functions.rst page we specify the current module for all the functions (or even just for int/float/etc) as __builtin__ and use the function directive, and in the stdtypes.rst (or elsewhere) we use the class directive?
The idea is to pretend that '__builtin__.int' is a function in the __builtin__ module whereas 'int' is a global object.  In this way :func/class:`int` will probably link to the stdtypes.rst page, and :func/class:`~__builtin__.int` can be used to link to the functions.rst page (or the other way around if we want to link to the functions.rst page more often).  This is only a workaround though (assuming that it works), changing Sphinx to be smarter might be a better option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Wed Jun  8 00:37:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jun 2011 22:37:54 +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: <1307486274.97.0.303163251011.issue11277@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Yes, you should check the Mac OS X version at runtime (as you should check the Linux kernel at runtime). platform.mac_ver() uses something like:

sysv = _gestalt.gestalt('sysv')
if sysv:
  major = (sysv & 0xFF00) >> 8
  minor = (sysv & 0x00F0) >> 4
  patch = (sysv & 0x000F)

Note: patch is not reliable with 'sysv', you have to use ('sys1','sys2','sys3').

So if you would like to check that you have Mac OS 10.7 or later, you can do something like:

sysv = _gestalt.gestalt('sysv')
__MAC_10_7 = (sysv and (sysv >> 4) >= 0x0a7)

In C, it should be something like:
-------
const OSType SYSV = 0x73797376U; /* 'sysv' in big endian */
SInt32 response;
OSErr iErr;
iErr = Gestalt(SYSV, &response);
if (iErr == 0 && (response >> 4) >= 0x0a7)
  /* have Mac OS >= 10.7 */
-------

I'm not sure of 0x73797376, I used hex(struct.unpack('!I', 'sysv')[0]).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Wed Jun  8 02:22:17 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 08 Jun 2011 00:22:17 +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: <1307492537.22.0.51370936094.issue11277@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Victor, please do not use magic constants like that in C.  The symbolic values are available in include files:

#include <CoreServices/CoreServices.h>
SInt32 major = 0;
SInt32 minor = 0;   
Gestalt(gestaltSystemVersionMajor, &major);
Gestalt(gestaltSystemVersionMinor, &minor);
if ((major == 10 && minor >= 7) || major >= 11) { ... }

(See, for instance, http://www.cocoadev.com/index.pl?DeterminingOSVersion and http://stackoverflow.com/questions/2115373/os-version-checking-in-cocoa. The code in platform and _gestalt.c could stand to be updated at some point.)

But, again, mmap should *not* be changed until 10.7 has been released and the Apple fix is verified and only if it makes sense to add the additional complexity.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Wed Jun  8 04:09:11 2011
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 08 Jun 2011 02:09:11 +0000
Subject: [issue12276] 3.x ignores sys.tracebacklimit=0
In-Reply-To: <1307436501.83.0.59684150491.issue12276@psf.upfronthosting.co.za>
Message-ID: <1307498951.77.0.4610638187.issue12276@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Is this the intended behavior then? I don't get the rationale for that change.

There is no way to completely supress traceback information now; for sys.tracebacklimit to be of any significance, it must be >= 1; 0 and negative values behave the same as it not being set (that is, a full traceback is printed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12276>
_______________________________________

From report at bugs.python.org  Wed Jun  8 05:10:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Jun 2011 03:10:58 +0000
Subject: [issue12282] ABCMeta import error during build
In-Reply-To: <1307502658.23.0.460185626535.issue12282@psf.upfronthosting.co.za>
Message-ID: <1307502658.23.0.460185626535.issue12282@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

After a make distclean I'm seeing the following output during a build of default.  It is possible my 2.7 install is borked, but I don't understand why python is apparently being called during a gcc step.  The build seems to succeed.

gcc -pthread -c  -g -O0 -Wall -Wstrict-prototypes    -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 "/usr/lib/python2.7/site.py", line 62, in <module>
    import os
  File "/usr/lib/python2.7/os.py", line 398, in <module>
    import UserDict
  File "/usr/lib/python2.7/UserDict.py", line 83, in <module>
    import _abcoll
  File "/usr/lib/python2.7/_abcoll.py", line 11, in <module>
    from abc import ABCMeta, abstractmethod
ImportError: cannot import name ABCMeta
Traceback (most recent call last):
  File "/usr/lib/python2.7/site.py", line 62, in <module>
    import os
  File "/usr/lib/python2.7/os.py", line 398, in <module>
    import UserDict
  File "/usr/lib/python2.7/UserDict.py", line 83, in <module>
    import _abcoll
  File "/usr/lib/python2.7/_abcoll.py", line 11, in <module>
    from abc import ABCMeta, abstractmethod
ImportError: cannot import name ABCMeta
Traceback (most recent call last):
  File "/usr/lib/python2.7/site.py", line 62, in <module>
    import os
  File "/usr/lib/python2.7/os.py", line 398, in <module>
    import UserDict
  File "/usr/lib/python2.7/UserDict.py", line 83, in <module>
    import _abcoll
  File "/usr/lib/python2.7/_abcoll.py", line 11, in <module>
    from abc import ABCMeta, abstractmethod
ImportError: cannot import name ABCMeta

----------
components: Build
messages: 137894
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: ABCMeta import error during build
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12282>
_______________________________________

From report at bugs.python.org  Wed Jun  8 06:06:38 2011
From: report at bugs.python.org (umedoblock)
Date: Wed, 08 Jun 2011 04:06:38 +0000
Subject: [issue12211] Better document math.copysign behavior.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1307505998.94.0.955672580021.issue12211@psf.upfronthosting.co.za>


umedoblock <umedoblock at gmail.com> added the comment:

I'm late, sorry.

I attached the patch for math.rst and mathmodule.c.

----------
Added file: http://bugs.python.org/file22278/issue_12211.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12211>
_______________________________________

From report at bugs.python.org  Wed Jun  8 07:11:35 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 08 Jun 2011 05:11:35 +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: <1307509895.91.0.750615785462.issue11941@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Here is an updated patch that uses the atim, ctim and mtim variables (which are assigned based on various #ifdefs).

This should now work on Linux, BSD and Windows.

----------
Added file: http://bugs.python.org/file22279/issue11941_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11941>
_______________________________________

From report at bugs.python.org  Wed Jun  8 09:56:01 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 08 Jun 2011 07:56:01 +0000
Subject: [issue12282] ABCMeta import error during build
In-Reply-To: <1307502658.23.0.460185626535.issue12282@psf.upfronthosting.co.za>
Message-ID: <1307519761.09.0.0768428358811.issue12282@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It's being called for hg:

   -DHGVERSION="\"`LC_ALL=C hg id -i .`\"" ...

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12282>
_______________________________________

From report at bugs.python.org  Wed Jun  8 11:24:35 2011
From: report at bugs.python.org (David Siroky)
Date: Wed, 08 Jun 2011 09:24:35 +0000
Subject: [issue12197] non-blocking SSL write in Windows sends large data but
	raises exception
In-Reply-To: <1306519609.32.0.152577977388.issue12197@psf.upfronthosting.co.za>
Message-ID: <1307525075.49.0.994783661382.issue12197@psf.upfronthosting.co.za>


David Siroky <siroky at dasir.cz> added the comment:

Sorry, I attached wrong example version. It uses repeated sslsock.write() of the same buffer after catching SSL_ERROR_WANT_WRITE. It delivers the full block but this is a blocking operation.

I'm troubled with non-blocking writes. But as I dig deeper into the problem it looks like an inconsistency in OpenSSL (Linux vs. MSW). In Linux sslsock.write() always (as far as I can tell) sends some or all of the data and returns the amount. Like the plain socket.send(). In Windows it raises an exception if the data is larger then some uncertain size (mostly 16kB).

I'm working on snakeMQ asynchronous messaging library where the "packeter" layer relies on the sock.send() returning actual amount of sent bytes. This is not working in Windows if the link uses SSL.

Tested on WinXP, py2.6, py3.2.

----------
Added file: http://bugs.python.org/file22280/ssl_sock_test_fix.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12197>
_______________________________________

From report at bugs.python.org  Wed Jun  8 12:32:32 2011
From: report at bugs.python.org (DDarko)
Date: Wed, 08 Jun 2011 10:32:32 +0000
Subject: [issue12283] python3.2 smtplib _quote_periods
In-Reply-To: <1307529152.41.0.398489022746.issue12283@psf.upfronthosting.co.za>
Message-ID: <1307529152.41.0.398489022746.issue12283@psf.upfronthosting.co.za>


New submission from DDarko <ddarko.dd at gmail.com>:

File "/usr/lib/python3.2/smtplib.py", line 166, in _quote_periods

def _quote_periods(bindata):
    return re.sub(br'(?m)^\.', '..', bindata)

should be:
return re.sub(br'(?m)^\.', b'..', bindata)

----------
components: Extension Modules
messages: 137899
nosy: DDarko
priority: normal
severity: normal
status: open
title: python3.2 smtplib _quote_periods
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12283>
_______________________________________

From report at bugs.python.org  Wed Jun  8 13:28:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Jun 2011 11:28:14 +0000
Subject: [issue12283] python3.2 smtplib _quote_periods
In-Reply-To: <1307529152.41.0.398489022746.issue12283@psf.upfronthosting.co.za>
Message-ID: <1307532494.89.0.562998044165.issue12283@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib) -Extension Modules
nosy: +r.david.murray
stage:  -> patch review
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12283>
_______________________________________

From report at bugs.python.org  Wed Jun  8 13:46:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Jun 2011 11:46:44 +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: <1307533604.71.0.565357992971.issue11941@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure if that's deliberate, but the new attributes don't appear in the result repr():

>>> s = os.stat("LICENSE")
>>> s
posix.stat_result(st_mode=33204, st_ino=524885, st_dev=2053, st_nlink=1, st_uid=500, st_gid=500, st_size=14597, st_atime=1307474138, st_mtime=1299630588, st_ctime=1299630588)
>>> s.st_mtim
(1299630588, 90781883)

In the docs, you also need a "versionchanged" tag to mention that the attributes were added in 3.3.

The patch fails to compile under Windows: MSVC forbids variable declarations after code (atim, ctim, mtim), you have to put them at the beginning of a block. Once this is fixed, it seems to work ok.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11941>
_______________________________________

From report at bugs.python.org  Wed Jun  8 14:21:15 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 08 Jun 2011 12:21:15 +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: <20110608122104.GA6570@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Ok, this patch could be used.
*Unless* the code is not protected by the GIL.

- Gestalt usage is a bit more complicated according to

    http://www.cocoadev.com/index.pl?DeterminingOSVersion

  unless Python only supports OS X 10.4 and later.
  (And platform.py correctly states that in _mac_ver_gestalt(),
  but see below.)

- Due to usage of Gestalt, '-framework CoreServices' must be
  linked against mmapmodule.c.
  The Python configuration stuff is interesting for me, i managed
  compilation by adding the line

    mmap mmapmodule.c -framework CoreServices

  to Modules/Setup, but i guess it's only OS X which is happy
  about that.

platform.py: _mac_ver_xml() should be dropped entirely according
to one of Ned Deily's links ("never officially supported"), and
_mac_ver_gestalt() obviously never executed because i guess it
would fail due to "versioninfo".  Unless i missed something.

By the way: where do you get the info from?  "sys1", "sys2",
"sys3"?  Cannot find it anywhere, only the long names, e.g.
gestaltSystemVersionXy.

Note that i've mailed Apple.  I did not pay 99$ or even 249$, so
i don't know if there will be a response.
--
Ciao, Steffen
sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

----------
Added file: http://bugs.python.org/file22281/11277.apple-fix-2.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
@@ -88,7 +88,8 @@
 
    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.
+   with physical backing store on operating systems where this is
+   necessary, e.g. OpenVMS, and some buggy versions of Mac OS X.
 
    This example shows a simple way of using :class:`mmap`::
 
diff --git a/Modules/mmapmodule.c b/Modules/mmapmodule.c
--- a/Modules/mmapmodule.c
+++ b/Modules/mmapmodule.c
@@ -25,6 +25,8 @@
 #define UNIX
 # ifdef __APPLE__
 #  include <fcntl.h>
+
+#  include <CoreServices/CoreServices.h>
 # endif
 #endif
 
@@ -65,6 +67,39 @@
 #define my_getpagesize getpagesize
 #endif
 
+# ifdef __APPLE__
+static void
+apple_osx_needs_fullsync(long *use_fullsync)
+{
+    /* Issue #11277: mmap(2) bug with >32 bit sparse files.
+     * Apple fixed the bug before announcement of OS X "Lion", but since we
+     * need to handle buggy versions, perform a once-only check to see if the
+     * running kernel requires the expensive sync.
+     * >0: F_FULLSYNC is required, <0: kernel has mmap(2) bug fixed */
+    SInt32 ver;
+
+    *use_fullsync = 1;
+    if (Gestalt(gestaltSystemVersion, &ver) != noErr && ver >= 0x1040) {
+        if (Gestalt(gestaltSystemVersionMajor, &ver) != noErr)
+            goto jleave;
+        if (ver > 10) {
+            *use_fullsync = -1;
+            goto jleave;
+        }
+
+        if (Gestalt(gestaltSystemVersionMinor, &ver) != noErr)
+            goto jleave;
+        if (ver >= 7) {
+            *use_fullsync = -1;
+            goto jleave;
+        }
+    }
+
+jleave:
+    return;
+}
+# endif /* __APPLE__ */
+
 #endif /* UNIX */
 
 #include <string.h>
@@ -1128,8 +1163,14 @@
 #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);
+    if (fd != -1) {
+        /* (GIL protected) */
+        static long use_fullsync /*= 0*/;
+        if (!use_fullsync)
+            apple_osx_needs_fullsync(&use_fullsync);
+        if (use_fullsync > 0)
+            (void)fcntl(fd, F_FULLFSYNC);
+    }
 #endif
 #ifdef HAVE_FSTAT
 #  ifdef __VMS

From report at bugs.python.org  Wed Jun  8 14:27:47 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 08 Jun 2011 12:27:47 +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: <1307536067.26.0.360363843847.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file22273/11277.apple-fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Wed Jun  8 14:47:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jun 2011 12:47:44 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1307537264.97.0.50726648981.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

mbcs.patch fixes PyUnicode_DecodeMBCS():
 - only use flags=0 if errors="replace" on Windows >= Vista or if errors="ignore" on Windows < Vista
 - support any error handler
 - support any code page (but the code page is hardcoded to CP_ACP)

My patch always tries to decode in strict mode. On decode error: it decodes byte per byte, and call unicode_decode_call_errorhandler() on error.

TODO:

 - don't use insize=1 (decode byte per byte): it doesn't work with multibyte encodings (like UTF-8)
 - use final in decode_mbcs_errors(): a multibyte character may be splitted between two chunks of INT_MAX bytes
 - fix all FIXME
 - patch also PyUnicode_EncodeMBCS()
 - implement suggested Martin's optimizations?
 - MB_ERR_INVALID_CHARS is not supported by some code pages (e.g. UTF-7 code page)

Is it necessary to write a NUL character at the end? ("*out = 0;")

It would be nice to support any code page, and maybe support more options (e.g. MB_COMPOSITE, MB_PRECOMPOSED, MB_USEGLYPHCHARS to decode).

It is possible to test different code pages by changing the hardcoded code_page value in PyUnicode_DecodeMBCS. Change your region in the control panel if you would like to change the Windows ANSI code page. You can also play with SetThreadLocale() and CP_THREAD_ACP to test the ANSI code page of the current thread.

----------
keywords: +patch
Added file: http://bugs.python.org/file22282/mbcs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Wed Jun  8 14:57:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jun 2011 12:57:24 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1307537844.71.0.260958440335.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Example with ANSI=cp932 (on Windows Seven):
 - b'abc\xffdef'.decode('mbcs', 'replace') gives 'abc\uf8f3def'
 - b'abc\xffdef'.decode('mbcs', 'ignore') gives 'abcdef'

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Wed Jun  8 14:59:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jun 2011 12:59:38 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1307537978.29.0.656999181742.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Example with ANSI=cp932 (on Windows Seven):
>  - b'abc\xffdef'.decode('mbcs', 'replace') gives 'abc\uf8f3def'
>  - b'abc\xffdef'.decode('mbcs', 'ignore') gives 'abcdef'

Oh, and b'\xff'.decode('mbcs', 'surrogateescape') gives '\udcff' as expected. At least for surrogateescape, it would be nice that mbcs supports any error handler on encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Wed Jun  8 15:39:42 2011
From: report at bugs.python.org (Jonas H.)
Date: Wed, 08 Jun 2011 13:39:42 +0000
Subject: [issue12284] argparse.ArgumentParser: usage example option
In-Reply-To: <1307540382.34.0.477677451975.issue12284@psf.upfronthosting.co.za>
Message-ID: <1307540382.34.0.477677451975.issue12284@psf.upfronthosting.co.za>


New submission from Jonas H. <jonas at lophus.org>:

I'd like to see an `examples` option added to argparse.ArgumentParser as found in many man pages.

This could also be done using the `epilog` option, but that misses the "%(proc)s" replacement which makes usage examples like this

  Example usage:
    ./script.py option1 option2

impossible.

----------
components: Library (Lib)
messages: 137905
nosy: jonash
priority: normal
severity: normal
status: open
title: argparse.ArgumentParser: usage example option
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12284>
_______________________________________

From report at bugs.python.org  Wed Jun  8 15:47:11 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 08 Jun 2011 13:47:11 +0000
Subject: [issue11549] Build-out an AST optimizer,
	moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1307540831.26.0.292184716752.issue11549@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As Raymond noted though, some of the block stack fiddling doesn't make sense until after the bytecode has already been generated. It's OK to have multiple optimisers at different layers, each taking care of the elements that are best suited to that level.

And yes, an updated patch against the current tip would be good. Of my earlier review comments, the ones I'd still like to see addressed are:
- finish clearing out the now redundant special casing of None/True/False
- separating out the non-AST related compiler tweaks (i.e. 3b and 3c and the associated test changes) into their own patch (including moving the relevant tests into a separate @cpython_only test case)

I'm still not 100% convinced on that latter set of changes, but I don't 
want my further pondering on those to hold up the rest of the patch. (they probably make sense, it's just that the AST level changes are much easier to review than the ones right down at the bytecode generation level - reviewing the latter means getting back up to speed on precisely how the block stack works and it will be a while before I get around to doing that. It's just one of those things where the details matter, but diving that deep into the compiler is such a rare occurrence that I have to give myself a refresher course each time it happens).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11549>
_______________________________________

From report at bugs.python.org  Wed Jun  8 15:51:59 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 08 Jun 2011 13:51:59 +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: <1307541119.79.0.601655314785.issue11277@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Steffen: _mac_ver_xml should not be dropped, it is a perfectly fine way to determine the system version.  Discussing it is also off-topic for this issue, please keep the discussion focussed.

Wrt. mailing Apple: I wouldn't expect and answer. Is there something specific you want to know? I'm currently at WWDC and might be able to ask the question at one of the labs (where Apple's engineers hang out).

If it is really necessary to check for the OS version to enable the OSX-specific bugfix it is possible to look at the uname information instead of using gestalt.  In particular something simular to this Python code:

   v = os.uname()[2]
   major = int(v.split('.')[0])
   if major <= 10:
      # We're on OSX 10.6 or earlier
      enableWorkaround()

This tests the kernel version instead of the system version, but until now the major version of the kernel has increased with every major release of the OS and I have no reason to suspect that Lion will be any different.

BTW2: OSX 10.7 is not released yet and should not be discussed in public fora, as you should know if you have legal access.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Wed Jun  8 15:55:29 2011
From: report at bugs.python.org (Jorgen Skancke)
Date: Wed, 08 Jun 2011 13:55:29 +0000
Subject: [issue12285] Unexpected behavior for 0 or negative processes in
	multiprocessing.pool()
In-Reply-To: <1307541329.07.0.743246465318.issue12285@psf.upfronthosting.co.za>
Message-ID: <1307541329.07.0.743246465318.issue12285@psf.upfronthosting.co.za>


New submission from Jorgen Skancke <jorgsk at nt.ntnu.no>:

A normal way to start a multiprocessing-pool is like this:

Multiprocessing.Pool(processes=some_number).

However, if 'some_number' is 0 or negative, Python hangs and must be killed. I would expect an error message of the type: "Number of processes must be at least 1".

Attaching a script that reproduces this.

I struggled a bit with this for a program that uses cpu_count() - 4 to calculate 'some_number'. Guess what happens when the number of cores is 4 :) Even though the fix is easy (if some_number < 1), it would be nice to be warned about it.

----------
components: Library (Lib)
files: multitest_pool.py
messages: 137908
nosy: jorgsk
priority: normal
severity: normal
status: open
title: Unexpected behavior for 0 or negative processes in multiprocessing.pool()
versions: Python 2.6
Added file: http://bugs.python.org/file22283/multitest_pool.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12285>
_______________________________________

From report at bugs.python.org  Wed Jun  8 16:28:00 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Jun 2011 14:28:00 +0000
Subject: [issue12284] argparse.ArgumentParser: usage example option
In-Reply-To: <1307540382.34.0.477677451975.issue12284@psf.upfronthosting.co.za>
Message-ID: <1307543280.78.0.778989292494.issue12284@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12284>
_______________________________________

From report at bugs.python.org  Wed Jun  8 16:33:51 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Jun 2011 14:33:51 +0000
Subject: [issue12282] ABCMeta import error during build
In-Reply-To: <1307502658.23.0.460185626535.issue12282@psf.upfronthosting.co.za>
Message-ID: <1307543631.73.0.604625171468.issue12282@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As far as I can tell my python2.7 installation is fine and bug free.  hg is working fine when called from the command line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12282>
_______________________________________

From report at bugs.python.org  Wed Jun  8 16:51:34 2011
From: report at bugs.python.org (higery)
Date: Wed, 08 Jun 2011 14:51:34 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1307461733.49.0.987510653631.issue12279@psf.upfronthosting.co.za>
Message-ID: <1307544694.83.0.217384234765.issue12279@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

Now, the workaround of my code is just setting the 'distinfo-dir' option with os.curdir value through calling a 'reinitialize_command(self, command, reinit_subcommands=False, **kw)' function , which is added in packaging's Command class for my own purpose, but I think it should be taken as a standard function in Command - it's useful and setuptools' Command class does have this function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Wed Jun  8 17:14:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Jun 2011 15:14:13 +0000
Subject: [issue12282] build process adds CWD (null entry) to PYTHONPATH if
	PYTHONPATH is set in the build environment
In-Reply-To: <1307502658.23.0.460185626535.issue12282@psf.upfronthosting.co.za>
Message-ID: <1307546053.2.0.273136321844.issue12282@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It turns out that I had a stray abc.py file in my current working directory as the result of some previous tests of module-load-order rules.  That by itself wouldn't have triggered the problem, but in addition, I have PYTHONPATH set in my environment because I have the hg whitespace hook installed.  Apparently the build process turns a non-empty PYTHONPATH into a null entry in the final computed PYTHONPATH it uses when hg is called, and this results in anything located in the CWD being loaded.

I don't think this rises quite to the level of a security issue, since it applies only at build time, but it certainly seems like a bug.

----------
title: ABCMeta import error during build -> build process adds CWD (null entry) to PYTHONPATH if PYTHONPATH is set in the build environment
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12282>
_______________________________________

From report at bugs.python.org  Wed Jun  8 17:23:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 08 Jun 2011 15:23:35 +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: <E1QUKbQ-0004DR-4S@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6d6099f7fe89 by Antoine Pitrou in branch 'default':
Issue #9205: concurrent.futures.ProcessPoolExecutor now detects killed
http://hg.python.org/cpython/rev/6d6099f7fe89

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Wed Jun  8 17:25:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Jun 2011 15:25:30 +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: <1307546730.69.0.457894542929.issue9205@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

So, concurrent.futures is fixed now. Unless someone wants to patch multiprocessing.Pool, I am closing this issue.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Wed Jun  8 17:52:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Jun 2011 15:52:30 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <1307548350.75.0.415570146007.issue12021@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch looks good to me, thank you :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12021>
_______________________________________

From report at bugs.python.org  Wed Jun  8 17:57:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Jun 2011 15:57:26 +0000
Subject: [issue12187] subprocess.wait() with a timeout uses polling on POSIX
In-Reply-To: <1306416741.33.0.363365904037.issue12187@psf.upfronthosting.co.za>
Message-ID: <1307548646.37.0.203835836782.issue12187@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why not use signalfd() when available?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12187>
_______________________________________

From report at bugs.python.org  Wed Jun  8 18:00:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Jun 2011 16:00:38 +0000
Subject: [issue12197] non-blocking SSL write in Windows sends large data but
	raises exception
In-Reply-To: <1307525075.49.0.994783661382.issue12197@psf.upfronthosting.co.za>
Message-ID: <1307548834.12682.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Sorry, I attached wrong example version. It uses repeated
> sslsock.write() of the same buffer after catching
> SSL_ERROR_WANT_WRITE. It delivers the full block but this is a
> blocking operation.

In "normal" non-blocking code you would use select() (or an equivalent)
until the socket is ready for writing, and then send() some chunk of
data on it. Can't you use that approach?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12197>
_______________________________________

From report at bugs.python.org  Wed Jun  8 19:18:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 08 Jun 2011 17:18:37 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <E1QUMOp-00068q-M3@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 964d0d65a2a9 by Charles-Fran?ois Natali in branch 'default':
Issue #12021: Make mmap's read() method argument optional. Patch by Petri
http://hg.python.org/cpython/rev/964d0d65a2a9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12021>
_______________________________________

From report at bugs.python.org  Wed Jun  8 19:39:47 2011
From: report at bugs.python.org (Johann C. Rocholl)
Date: Wed, 08 Jun 2011 17:39:47 +0000
Subject: [issue12286] float('nan') breaks sort() method on a list of floats
In-Reply-To: <1307554787.91.0.244945318639.issue12286@psf.upfronthosting.co.za>
Message-ID: <1307554787.91.0.244945318639.issue12286@psf.upfronthosting.co.za>


New submission from Johann C. Rocholl <jcrocholl at google.com>:

>>> l = [1.0, 2.0, 3.0, float('nan'), 4.0, 3.0, 2.0, 1.0]
>>> l.sort()
>>> l
[1.0, 2.0, 3.0, nan, 1.0, 2.0, 3.0, 4.0]

The expected result is either of the following:
[nan, 1.0, 1.0, 2.0, 2.0, 3.0, 3.0, 4.0] (similar to None)
[1.0, 1.0, 2.0, 2.0, 3.0, 3.0, 4.0, nan] (similar to string 'nan')

----------
messages: 137918
nosy: jcrocholl
priority: normal
severity: normal
status: open
title: float('nan') breaks sort() method on a list of floats
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12286>
_______________________________________

From report at bugs.python.org  Wed Jun  8 19:44:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 08 Jun 2011 17:44:58 +0000
Subject: [issue12286] float('nan') breaks sort() method on a list of floats
In-Reply-To: <1307554787.91.0.244945318639.issue12286@psf.upfronthosting.co.za>
Message-ID: <1307555098.86.0.608491585243.issue12286@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is expected.  See also #11986 and #11949.

----------
nosy: +belopolsky, ezio.melotti, mark.dickinson, rhettinger
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12286>
_______________________________________

From report at bugs.python.org  Wed Jun  8 20:13:29 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 08 Jun 2011 18:13:29 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <1307556809.59.0.241245589397.issue12021@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Patch committed.
Thanks for the report and the patch!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12021>
_______________________________________

From report at bugs.python.org  Wed Jun  8 20:24:07 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Jun 2011 18:24:07 +0000
Subject: [issue12286] float('nan') breaks sort() method on a list of floats
In-Reply-To: <1307554787.91.0.244945318639.issue12286@psf.upfronthosting.co.za>
Message-ID: <1307557447.96.0.527293082997.issue12286@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This is actually a duplicate of issue7915.

I don't think there is nothing we can do to improve the situation.  In fact discussion at #11949 ends with a +0 from Mark Dickinson to issue a warning whenever nans participate in order comparison. Discussion at #11986 ends without any clear consensus.  I think we should keep at least one issue on this topic open rather than close new issues as invalid by referring users to older closed issues that don't explain why silently producing nonsensical results is better than raising an error or issuing a warning.

----------
resolution: invalid -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12286>
_______________________________________

From report at bugs.python.org  Wed Jun  8 20:52:14 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 08 Jun 2011 18:52:14 +0000
Subject: [issue12197] non-blocking SSL write in Windows sends large data but
	raises exception
In-Reply-To: <1306519609.32.0.152577977388.issue12197@psf.upfronthosting.co.za>
Message-ID: <1307559134.71.0.288255783345.issue12197@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12197>
_______________________________________

From report at bugs.python.org  Wed Jun  8 20:57:28 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 08 Jun 2011 18:57:28 +0000
Subject: [issue12187] subprocess.wait() with a timeout uses polling on POSIX
In-Reply-To: <1306416741.33.0.363365904037.issue12187@psf.upfronthosting.co.za>
Message-ID: <1307559448.63.0.598543563257.issue12187@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12187>
_______________________________________

From report at bugs.python.org  Wed Jun  8 21:02:34 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 08 Jun 2011 19:02:34 +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: <1307559754.69.0.266959730271.issue8407@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Wed Jun  8 21:24:46 2011
From: report at bugs.python.org (Tom Whittock)
Date: Wed, 08 Jun 2011 19:24:46 +0000
Subject: [issue1195571] simple callback system for Py_FatalError
Message-ID: <1307561086.15.0.159864557361.issue1195571@psf.upfronthosting.co.za>


Changes by Tom Whittock <tom.whittock at gmail.com>:


----------
nosy: +Tom.Whittock

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195571>
_______________________________________

From report at bugs.python.org  Wed Jun  8 21:36:41 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 08 Jun 2011 19:36:41 +0000
Subject: [issue1195571] simple callback system for Py_FatalError
Message-ID: <1307561801.11.0.479932192278.issue1195571@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

This makes sense, I'll add it to 3.3.

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195571>
_______________________________________

From report at bugs.python.org  Wed Jun  8 22:37:15 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 08 Jun 2011 20:37:15 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

ossaudiodev's writeall method doesn't check that the FD is less than FD_SETSIZE when passing it to FD_SET: since FD_SET typically doesn't do bound check, it will write to a random location in memory (in this case on the stack).
I've attached a test that triggers a segfault on my 32-bit Linux box:
- you must have an OSS-compatible device as /dev/dsp (if you don't you can use "modprobe snd_pcm_oss")
- it tries to increase RLIMIT_NOFILE since it's usually defined to be the same as FD_SETSIZE (1024 on Linux). The script must be run as root for that.
A patch is attached.
The only other place where I've seen a similar problem is in Module/readline.c: I'm not sure it's worth adding this check there :-)

----------
components: Library (Lib)
files: oss_select.diff
keywords: needs review, patch
messages: 137923
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: ossaudiodev: stack corruption with FD >= FD_SETSIZE
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22284/oss_select.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Wed Jun  8 22:37:33 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 08 Jun 2011 20:37:33 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1307565453.46.0.293899645118.issue12287@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file22285/test_oss.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Wed Jun  8 22:43:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Jun 2011 20:43:57 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1307565832.3651.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> ossaudiodev's writeall method doesn't check that the FD is less than
> FD_SETSIZE when passing it to FD_SET: since FD_SET typically doesn't
> do bound check, it will write to a random location in memory (in this
> case on the stack).
> I've attached a test that triggers a segfault on my 32-bit Linux box:
> - you must have an OSS-compatible device as /dev/dsp (if you don't you
> can use "modprobe snd_pcm_oss")
> - it tries to increase RLIMIT_NOFILE since it's usually defined to be
> the same as FD_SETSIZE (1024 on Linux). The script must be run as root
> for that.
> A patch is attached.

Well, the test doesn't work here ("IOError: [Errno 16] Device or
resource busy: '/dev/dsp'", probably because of PulseAudio already using
it), but the patch looks simple enough.

By the way, this function still uses "y#" instead of "y*", this could be
the topic of another issue if you are interested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Wed Jun  8 23:28:03 2011
From: report at bugs.python.org (Tom Middleton)
Date: Wed, 08 Jun 2011 21:28:03 +0000
Subject: [issue12288] Python 2.7.1 tkSimpleDialog initialvalue
In-Reply-To: <1307568483.64.0.2959467561.issue12288@psf.upfronthosting.co.za>
Message-ID: <1307568483.64.0.2959467561.issue12288@psf.upfronthosting.co.za>


New submission from Tom Middleton <busfault at gmail.com>:

Using Tkinter under Python 2.7.1 (Windows XP FWIF)
If using the tkSimpleDialog.askinteger() function with an initialvalue = 0, the 0 is not displayed in the dialog box. The same is true for tkSimpleDialog.askfloat().

The cause of this seems to be the following:
in Lib\libi-tk\tkSimpleDialog.py (attached for convenience) 
under class _QueryDialog(Dialog)

    def body(self, master):

        w = Label(master, text=self.prompt, justify=LEFT)
        w.grid(row=0, padx=5, sticky=W)

        self.entry = Entry(master, name="entry")
        self.entry.grid(row=1, padx=5, sticky=W+E)

        if self.initialvalue:
            self.entry.insert(0, self.initialvalue)
            self.entry.select_range(0, END)

        return self.entry

The if self.initialvalue will evaluate to a FALSE when the initial value is a 0.

Changing this line to:

if self.initialvalue is not None:

fixed this issue.
I am not certain that this is as intended or a bug.

----------
components: Tkinter
files: tkSimpleDialog.py
messages: 137925
nosy: busfault
priority: normal
severity: normal
status: open
title: Python 2.7.1 tkSimpleDialog initialvalue
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file22286/tkSimpleDialog.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12288>
_______________________________________

From report at bugs.python.org  Wed Jun  8 23:33:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jun 2011 21:33:32 +0000
Subject: [issue1195571] simple callback system for Py_FatalError
Message-ID: <1307568812.55.0.931655603527.issue1195571@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

fatalhook-2.patch: I don't understand the documentation. It says "Cause :cfunc:`Py_FatalError` to invoke the given function instead of printing to standard error and aborting out of the process.", but if the callback does nothing, the message+traceback is printed.

If the "fatal hook" is supposed to replace the function displaying the message, you should move the code displaying message+traceback in a subfunction and use it as the default hook function.

Pseudo code:
---------------
static fatal_error(const char *msg)
{
   printf("Fatal error: %s\n", msg);
   ... print traceback ...
}

static PyFatalHook fatalhook_func = fatal_error;

void
Py_FatalError(const char *msg)
{
    if (fatalhook_func != NULL)
       fatalhook_func(msg);
    ... windows debugger code ...
    abort();
}
---------------

NULL is a special hook value: don't print message+traceback, but exit (call abort()).

The hook can exit the process using something else than abort(). But if the hook doesn't exit, the default exit code is executed (call abort()), but the "Fatal error..."+traceback is not printed.

> fatalhook_func != Py_FatalError

I think that this test is just overkill, or it should be moved to Py_SetFatalHook (e.g. set the hook to NULL if Py_FatalError is passed).

> I also made Py_SetFatalHook() return the previous hook; 
> it could be useful to set a function temporarily,
> even if this is not thread safe.

The previous hook can also be used to chain hooks. For example, if you would like to display the traceback but also do a special thing before exit, you can do something like:
------------------
void init()
{
   previous = Py_SetFatalHook(my_hook)
}

void my_hook(const char *msg)
{
  ... cleanup ...
  previous(msg);
}
------------------

About thread safety: because Py_FatalError() is called in the worst case (when something really bad happens), I think that it is better to not use something related to thread to avoid issues like deadlocks, and keep the code simple.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195571>
_______________________________________

From report at bugs.python.org  Wed Jun  8 23:53:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jun 2011 21:53:06 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1307569986.96.0.534178412085.issue12287@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You don't check that 0 <= fd (e.g. oss.close()).

The select has a specific code for Visual Studio (don't check v < FD_SETSIZE):

#if defined(_MSC_VER)
        max = 0;                             /* not used for Win32 */
#else  /* !_MSC_VER */
        if (v < 0 || v >= FD_SETSIZE) {
            PyErr_SetString(PyExc_ValueError,
                        "filedescriptor out of range in select()");
            goto finally;
        }
        if (v > max)
            max = v;
#endif /* _MSC_VER */

Python has a _PyVerify_fd() function. We might write a similar function/macro to check if a file descriptor can be used in a file descriptor set. FD_SET() is used in the oss, readline, socket and _ssl modules. The socket module has a IS_SELECTABLE() macro:

#ifdef Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE
/* Platform can select file descriptors beyond FD_SETSIZE */
#define IS_SELECTABLE(s) 1
#elif defined(HAVE_POLL)
/* Instead of select(), we'll use poll() since poll() works on any fd. */
#define IS_SELECTABLE(s) 1
/* Can we call select() with this socket without a buffer overrun? */
#else
/* POSIX says selecting file descriptors beyond FD_SETSIZE
   has undefined behaviour.  If there's no timeout left, we don't have to
   call select, so it's a safe, little white lie. */
#define IS_SELECTABLE(s) ((s)->sock_fd < FD_SETSIZE || s->sock_timeout <= 0.0)
#endif

Note: do you really use the OSS module? On which OS? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Thu Jun  9 00:00:38 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 08 Jun 2011 22:00:38 +0000
Subject: [issue12187] subprocess.wait() with a timeout uses polling on POSIX
In-Reply-To: <1306416741.33.0.363365904037.issue12187@psf.upfronthosting.co.za>
Message-ID: <1307570438.14.0.542273800992.issue12187@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> For subprocess.wait(), we can do something with signals (SIGCHLD and/or SIGCLD).

There's just one problem: SIGCHLD is ignored by default, which means that sigwait and friends won't return when a child exits.
Well, it actually works on recent Linux kernels, but POSIX makes no such guarantee, and it's at least known to fail on Solaris (see Dave Butenhof's comment):
http://www.multithreadedprogramming.info/sigwait-ing-for-sigchld

To be portable, we would need to set a handler for SIGCHLD, which has the following problems:
- you have to do that from the main thread
- it impacts every thread
- it will make syscalls fail with EINTR
- once you've changed SIGCHLD setting, you can't go back to the original semantic (setting it to SIG_IGN again will prevent children from becoming zombies, and waitpid wait until all children exited and will fail with ECHILD)

Note that even if it does work, there's a problem in multi-threaded programs, because the signal must be blocked by all the threads...

But since we use it with a timeout, we could also consider that this will work on systems that allow ignore signals to be catched by sigtimedwait, and it will wait the full timeout on other systems. I don't know if that's acceptable.

> Why not use signalfd() when available?

It suffers from the same issue, and it's Linux-specific (sigwait and friends are POSIX).

Note that exposing sigtimedwait is probably useful anyway, and I'd like to work on a patch.
Note that I'm not sure that exposing sigtimedwait is necessary (I don't think that the info field is going to be used by Python applications): how about just adding an optional timeout argument to signal_sigwait?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12187>
_______________________________________

From report at bugs.python.org  Thu Jun  9 00:29:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jun 2011 22:29:00 +0000
Subject: [issue12187] subprocess.wait() with a timeout uses polling on POSIX
In-Reply-To: <1306416741.33.0.363365904037.issue12187@psf.upfronthosting.co.za>
Message-ID: <1307572140.77.0.125739321687.issue12187@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> To be portable, we would need to ...

Antoine is right: we don't have to be portable. We can write an "optimized" implementations (without polling) for a specific OS, even for a specific version of an OS (e.g. like Linux kernel >= 2.6.22 for signalfd).

I like the idea of signalfd(), but I don't know exactly how it works. Should we block the signal? What happens when we unblock the signal? It would be nice if the signal handler is called on unblock, because it would not change the current behaviour. Is it possible to block a signal in all threads? pthread_sigmask() blocks signals in the current thread, the manual page of sigprocmask() has a funny comment: "The use of sigprocmask() is unspecified in a multithreaded process; see pthread_sigmask(3)."

Extract of signalfd() manual page: "Normally,  the  set of signals to be received via the file descriptor should be blocked using sigprocmask(2), to prevent the signals being handled according to their default dispositions."

Is SIGCHLD only raised once at child process exit? "SIGCLD would be delivered constantly (unless blocked) while any child is ready to be waited for." according to http://lwn.net/Articles/414618/

> There's just one problem: SIGCHLD is ignored by default,
> which means that sigwait and friends won't return when a child exits.

sigwait() is not impacted by the associated signal handler, but sigwait() only works if the signal is blocked (e.g. by pthread_sigmask):

"If no signal in set is pending at the time of the call, the thread is suspended until one or more becomes pending. The signals defined by set will been blocked at the time of the call to sigwait(); otherwise the behaviour is undefined."
http://pubs.opengroup.org/onlinepubs/007908799/xsh/sigwait.html

Example (for Python 3.3):
--------------------------
from signal import *
import subprocess

signum = SIGCHLD
process = subprocess.Popen("sleep 1", shell=True)
print("Wait %s..." % signum)
pthread_sigmask(SIG_BLOCK, [signum])
sigwait([signum])
pthread_sigmask(SIG_UNBLOCK, [signum])
print("done")
process.wait()
--------------------------

Same question than signalfd(): how can we block a signal in all threads (including C threads, e.g. _tkinter event looop thread)? Use sigprocmask()?

sigwait() removes the signal from the list of pending signals, so the signal handler will not be called.

> Note that exposing sigtimedwait is probably useful anyway,
> and I'd like to work on a patch.

See also issue #8407 for sigtimedwait() and signalfd() in Python.

---

sigprocmask(), sigwait() and signals in general seem to behave differently on each OS, so anyway, we cannot write a single portable implementation to solve this issue. If we cannot write a reliable non-polling implementation for an OS, you should use the polling implementation instead (which *is* reliable).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12187>
_______________________________________

From report at bugs.python.org  Thu Jun  9 01:47:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jun 2011 23:47:27 +0000
Subject: [issue12289] http.server.CGIHTTPRequestHandler doesn't check if a
	Python script is executable
In-Reply-To: <1307576847.86.0.0933852341785.issue12289@psf.upfronthosting.co.za>
Message-ID: <1307576847.86.0.0933852341785.issue12289@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

CGIHTTPRequestHandler.run_cgi() only checks if the script processing the request is executable if the file is not a Python script, but later it uses os.execve(scriptfile, ...) if os has a fork() function.

Moreover, the executable() functions checks if os.stat(path).st_mode & 0o111 != 0: this test is wrong if st_mode & 0o111 != 0o111. For example, if the script has mode 0700 and is not owned by the current user, executable() returns True, whereas it should be False. os.access(filename, os.X_OK) should be used instead.

I found these issues while trying to understand the following failure on "FreeBSD 7.2 x86 3.x" buildbot:

[320/356/2] test_httpservers
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/http/server.py", line 1123, in run_cgi
OSError: [Errno 13] Permission denied
(...)

I don't understand how it happens because test_httpservers uses os.chmod(script, 0o777).

----------
components: Library (Lib)
messages: 137930
nosy: haypo
priority: normal
severity: normal
status: open
title: http.server.CGIHTTPRequestHandler doesn't check if a Python script is executable
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12289>
_______________________________________

From report at bugs.python.org  Thu Jun  9 02:00:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Jun 2011 00:00:28 +0000
Subject: [issue11583] os.path.isdir() is slow on windows
In-Reply-To: <1300354713.42.0.570312056806.issue11583@psf.upfronthosting.co.za>
Message-ID: <E1QUSfj-0005Og-0v@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 88e318166eaf by Brian Curtin in branch '3.2':
Fix #11583. Changed os.path.isdir to use GetFileAttributes instead of os.stat.
http://hg.python.org/cpython/rev/88e318166eaf

New changeset 567f30527913 by Brian Curtin in branch 'default':
Fix #11583. Changed os.path.isdir to use GetFileAttributes instead of os.stat.
http://hg.python.org/cpython/rev/567f30527913

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11583>
_______________________________________

From report at bugs.python.org  Thu Jun  9 02:31:49 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 09 Jun 2011 00:31:49 +0000
Subject: [issue11583] os.path.isdir() is slow on windows
In-Reply-To: <1300354713.42.0.570312056806.issue11583@psf.upfronthosting.co.za>
Message-ID: <1307579509.47.0.208353356066.issue11583@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

This was also pushed to 2.7 in f1509fc75435.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11583>
_______________________________________

From report at bugs.python.org  Thu Jun  9 02:35:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jun 2011 00:35:44 +0000
Subject: [issue12285] Unexpected behavior for 0 or negative processes in
	multiprocessing.pool()
In-Reply-To: <1307541329.07.0.743246465318.issue12285@psf.upfronthosting.co.za>
Message-ID: <1307579744.63.0.0876966690167.issue12285@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

multiprocessing_pool.patch: raise a ValueError if processes is less than 1. A test should be added.

----------
keywords: +patch
nosy: +haypo
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6
Added file: http://bugs.python.org/file22287/multiprocessing_pool.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12285>
_______________________________________

From report at bugs.python.org  Thu Jun  9 02:42:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jun 2011 00:42:40 +0000
Subject: [issue12289] http.server.CGIHTTPRequestHandler doesn't check if a
	Python script is executable
In-Reply-To: <1307576847.86.0.0933852341785.issue12289@psf.upfronthosting.co.za>
Message-ID: <1307580160.11.0.247319389177.issue12289@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

cgi.patch: fix the test checking that the script file is executable.

The patch removes the executable() function. This function is not documented but is public. The patch can be easily modified to keep this function if needed.

----------
keywords: +patch
Added file: http://bugs.python.org/file22288/cgi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12289>
_______________________________________

From report at bugs.python.org  Thu Jun  9 04:21:00 2011
From: report at bugs.python.org (Eugene Toder)
Date: Thu, 09 Jun 2011 02:21:00 +0000
Subject: [issue12290] __setstate__ is called for false values
In-Reply-To: <1307586060.34.0.652262251036.issue12290@psf.upfronthosting.co.za>
Message-ID: <1307586060.34.0.652262251036.issue12290@psf.upfronthosting.co.za>


New submission from Eugene Toder <eltoder at gmail.com>:

Pickle documentation [1] says:

""" Note: If __getstate__() returns a false value, the __setstate__() method will not be called upon unpickling. """

However, this isn't quite true. This depends on the version of pickle protocol. A small example:

>>> class Pockle(object):
	def __getstate__(self):
		return 0
	def __setstate__(self, state):
		sys.stdout.write('__setstate__ is called!\n')

>>> for p in range(4):
	sys.stdout.write('protocol %d: ' % p)
	pickle.loads(pickle.dumps(Pockle(), p))

protocol 0: <__main__.Pockle object at 0x0000000002EAE3C8>
protocol 1: <__main__.Pockle object at 0x0000000002EAE358>
protocol 2: __setstate__ is called!
<__main__.Pockle object at 0x0000000002EAE3C8>
protocol 3: __setstate__ is called!
<__main__.Pockle object at 0x0000000002EAE358>

So for protocols >= 2 setstate is called. This is caused by object.__reduce_ex__ returning different tuples for different protocol versions:

>>> for p in range(4):
	sys.stdout.write('protocol %d: %s\n' % (p, Pockle().__reduce_ex__(p)))

	
protocol 0: (<function _reconstructor at 0x0000000001F03048>, (<class '__main__.Pockle'>, <class 'object'>, None))
protocol 1: (<function _reconstructor at 0x0000000001F03048>, (<class '__main__.Pockle'>, <class 'object'>, None))
protocol 2: (<function __newobj__ at 0x0000000001F03148>, (<class '__main__.Pockle'>,), 0, None, None)
protocol 3: (<function __newobj__ at 0x0000000001F03148>, (<class '__main__.Pockle'>,), 0, None, None)

Implementation of reduce_ex for protos 0-1 in copy_reg.py contains the documented check: http://hg.python.org/cpython/file/f1509fc75435/Lib/copy_reg.py#l85

Implementation for proto 2+ in typeobject.c is happy with any value: http://hg.python.org/cpython/file/f1509fc75435/Objects/typeobject.c#l3205

Pickle itself only ignores None, not any false value: http://hg.python.org/cpython/file/f1509fc75435/Lib/pickle.py#l418

I think this is a documentation issue at this point.

[1] http://docs.python.org/py3k/library/pickle.html#pickle.object.__setstate__

----------
components: Library (Lib)
messages: 137935
nosy: eltoder
priority: normal
severity: normal
status: open
title: __setstate__ is called for false values
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/issue12290>
_______________________________________

From report at bugs.python.org  Thu Jun  9 04:37:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Jun 2011 02:37:23 +0000
Subject: [issue12290] __setstate__ is called for false values
In-Reply-To: <1307586060.34.0.652262251036.issue12290@psf.upfronthosting.co.za>
Message-ID: <1307587043.46.0.249792306297.issue12290@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also #6827, just for some background on the current docs.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12290>
_______________________________________

From report at bugs.python.org  Thu Jun  9 04:59:01 2011
From: report at bugs.python.org (Eugene Toder)
Date: Thu, 09 Jun 2011 02:59:01 +0000
Subject: [issue12290] __setstate__ is called for false values
In-Reply-To: <1307586060.34.0.652262251036.issue12290@psf.upfronthosting.co.za>
Message-ID: <1307588341.32.0.631119549271.issue12290@psf.upfronthosting.co.za>


Changes by Eugene Toder <eltoder at gmail.com>:


----------
nosy: +alexandre.vassalotti, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12290>
_______________________________________

From report at bugs.python.org  Thu Jun  9 05:18:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Jun 2011 03:18:23 +0000
Subject: [issue12243] getpass.getuser works on OSX
In-Reply-To: <1307029704.02.0.858553376312.issue12243@psf.upfronthosting.co.za>
Message-ID: <1307589503.83.0.950800606548.issue12243@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It requires adding code to support a new Sphinx directive.  I'm not sure if it should be a generic Sphinx directive (in which case we should open an issue on the Sphinx bug tracker) or Python specific.  If the latter, I can't at the moment tell you where the python-specific Sphinx code lives, but someone will know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12243>
_______________________________________

From report at bugs.python.org  Thu Jun  9 06:06:48 2011
From: report at bugs.python.org (michael mulich)
Date: Thu, 09 Jun 2011 04:06:48 +0000
Subject: [issue10884] pkgutil EggInfoDistribution requirements for .egg-info
	metadata
In-Reply-To: <1307374426.06.0.858520577361.issue10884@psf.upfronthosting.co.za>
Message-ID: <BANLkTikRM=mRCnsDBsMgPesXao=5GhbH_Q@mail.gmail.com>


michael mulich <michael.mulich at gmail.com> added the comment:

Sure, I'll have a look. I'm only getting back into the swing of
things, but hopefully I can get more involved. Trying to do one or two
small tasks a night.

-Michael Mulich (pumazi)

On Mon, Jun 6, 2011 at 11:33 AM, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Can you check if this is covered in test_database?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10884>
> _______________________________________
>

----------
nosy: +michael.mulich2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10884>
_______________________________________

From report at bugs.python.org  Thu Jun  9 06:19:55 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 09 Jun 2011 04:19:55 +0000
Subject: [issue11583] os.path.isdir() is slow on windows
In-Reply-To: <1300354713.42.0.570312056806.issue11583@psf.upfronthosting.co.za>
Message-ID: <1307593195.24.0.662108728832.issue11583@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Brian - great, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11583>
_______________________________________

From report at bugs.python.org  Thu Jun  9 07:56:15 2011
From: report at bugs.python.org (Julian Mehnle)
Date: Thu, 09 Jun 2011 05:56:15 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1307598975.12.0.308785902337.issue7946@psf.upfronthosting.co.za>


Changes by Julian Mehnle <julian at mehnle.net>:


----------
nosy: +jmehnle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Thu Jun  9 08:13:10 2011
From: report at bugs.python.org (Julian Mehnle)
Date: Thu, 09 Jun 2011 06:13:10 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1307599990.19.0.963538720355.issue7753@psf.upfronthosting.co.za>


Changes by Julian Mehnle <julian at mehnle.net>:


----------
nosy: +jmehnle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Thu Jun  9 09:38:09 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 09 Jun 2011 07:38:09 +0000
Subject: [issue9284] inspect.findsource() cannot find source for doctest code
In-Reply-To: <1279372617.05.0.528440876901.issue9284@psf.upfronthosting.co.za>
Message-ID: <1307605089.63.0.715882690748.issue9284@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Would it still be possible to get this into 2.7.2? It's a 2.6-2.7 regression, would be nice to fix, and it seems fairly low-impact.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9284>
_______________________________________

From report at bugs.python.org  Thu Jun  9 09:47:03 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 09 Jun 2011 07:47:03 +0000
Subject: [issue12187] subprocess.wait() with a timeout uses polling on POSIX
In-Reply-To: <1306416741.33.0.363365904037.issue12187@psf.upfronthosting.co.za>
Message-ID: <1307605623.05.0.764999799988.issue12187@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Antoine is right: we don't have to be portable. 

We don't have to, but writing one POSIX-conformant solution is better than writing N OS-specific solutions, no? That's what POSIX is about.

> Should we block the signal?

Yes.

> What happens when we unblock the signal?

If you've read from the FD, nothing, since it consumes the pending signals. If you haven't, since signal_pthread_sigmask checks for pending signals, I guess that the handler will be called upon unblock. But signalfd is designed as an alternative to handlers, so I don't think this makes much sense, and if a SIGCHLD handler is setup, it's likely to perform a waitpid(-1, WNOHANG), which will screw up our waiting anyway...

> Is it possible to block a signal in all threads?

Not portably.

> sigwait() is not impacted by the associated signal handler, but sigwait() only works if the signal is blocked (e.g. by pthread_sigmask):

The point I was making is precisely that blocking the signal is not enough on some kernels: when the signal is ignored, it will sometimes not wakeup threads waiting on sigwait.

> sigprocmask(), sigwait() and signals in general seem to behave differently on each OS

They behave correctly as long as they're used in a POSIX-conformant way. To sum up, those problems are:
- since SIGCHLD is ignored by default, some kernels won't wake up threads waiting on sigwait (it works on Linux, don't know for *BSD kernels)
- there's not portable way to block signals in all threads.
As a consequence, there will be cases where sigtimedwait or select on a signalfd will wait until the end of the timeout.

> See also issue #8407 for sigtimedwait() and signalfd() in Python.

You didn't commit the signalfd part?
Whay do you think of sigtimedwait?
Expose it as-is, or just add an optional timeout option to sigwait?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12187>
_______________________________________

From report at bugs.python.org  Thu Jun  9 10:08:59 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Jun 2011 08:08:59 +0000
Subject: [issue1195571] simple callback system for Py_FatalError
Message-ID: <1307606939.09.0.115884966256.issue1195571@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Sorry, the documentation in the patch is wrong. It should be: "Cause :cfunc:`Py_FatalError` to invoke the given function before printing to standard error and aborting out of the process."

I don't think it's worth making it more complex.  If the application does not want the default behavior (which is already quite minimal anyway), it can always install a hook that never returns.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195571>
_______________________________________

From report at bugs.python.org  Thu Jun  9 11:10:10 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 09 Jun 2011 09:10:10 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

The attached file 'data.bin' was written using Python 3.2. It can be read by Python 2.7, but in 3.2 and 3.3, after the first object is read, the file pointer is positioned at EOF, causing an error on subsequent reads. A simple test script 'marshtest.py' is below:

import marshal
import sys

f = open('data.bin', 'rb')
t = marshal.load(f)
print('Python version:', sys.version)
print('Object just loaded was:\n%r' % (t,))
print('File position is now at %d' % f.tell())
t = marshal.load(f)
print('Object just loaded was:\n%r' % (t,))
print('File position is now at %d' % f.tell())

Results of running it under various Python versions:

vinay at eta-natty:~/projects/scratch$ python marshtest.py 
('Python version:', '2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) \n[GCC 4.5.2]')
Object just loaded was:
(u'text', u'alfa', 202, 1.0, '\x00\x00\x00\x01]q\x00K\x03a')
File position is now at 52
Object just loaded was:
(u'text', u'alfa', 212, 1.0, '\x00\x00\x00\x01]q\x00K\x03a')
File position is now at 104

vinay at eta-natty:~/projects/scratch$ python3.2 marshtest.py 
Python version: 3.2 (r32:88445, Mar 25 2011, 19:28:28) 
[GCC 4.5.2]
Object just loaded was:
('text', 'alfa', 202, 1.0, b'\x00\x00\x00\x01]q\x00K\x03a')
File position is now at 53617
Traceback (most recent call last):
  File "marshtest.py", line 9, in <module>
    t = marshal.load(f)
EOFError: EOF read where object expected

vinay at eta-natty:~/projects/scratch$ python3.3 marshtest.py 
Python version: 3.3a0 (default:8d4d87dd73ae, Apr  2 2011, 14:25:31) 
[GCC 4.5.2]
Object just loaded was:
('text', 'alfa', 202, 1.0, b'\x00\x00\x00\x01]q\x00K\x03a')
File position is now at 53617
Traceback (most recent call last):
  File "marshtest.py", line 9, in <module>
    t = marshal.load(f)
EOFError: EOF read where object expected

Note the size of the file is 53617 bytes.

vinay at eta-natty:~/projects/scratch$ ls -l data.bin
-rw------- 1 vinay vinay 53617 2011-06-09 09:33 data.bin

----------
files: data.bin
messages: 137943
nosy: vinay.sajip
priority: normal
severity: normal
status: open
title: file written using marshal in 3.2 can be read by 2.7, but not 3.2 or 3.3
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file22289/data.bin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Thu Jun  9 11:31:48 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Jun 2011 09:31:48 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1307611908.37.0.718312211999.issue12291@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Sadly, marshal.load() looks broken:

- The function starts with the comment
    /* XXX Quick hack -- need to do this differently */

- It starts by calling f.read() which consumes the whole file (and explains the issue reported here)

- The code was probably converted too quickly:
    if (PyBytes_Check(data)) {
          ...
    else if (PyBytes_Check(data)) {

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Thu Jun  9 12:33:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jun 2011 10:33:42 +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: <1307615622.95.0.282461039492.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Oooooh, sigwait() doesn't accept a timeout! I would be nice to have
> also sigwaitinfo().. and maybe also its friend, sigwaitinfo() 

Oops, I mean sigtimedwait() and sigwaitinfo().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Thu Jun  9 12:37:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jun 2011 10:37:19 +0000
Subject: [issue12187] subprocess.wait() with a timeout uses polling on POSIX
In-Reply-To: <1306416741.33.0.363365904037.issue12187@psf.upfronthosting.co.za>
Message-ID: <1307615839.65.0.611175997001.issue12187@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(I should not answer in this issue, but in #8407)

> > See also issue #8407 for sigtimedwait() and signalfd() in Python.
>
> You didn't commit the signalfd part?

Not yet because I would like to provide something to decode the data written into the signalfd file descriptor (msg135438), the signalfd_siginfo structure.

> Whay do you think of sigtimedwait?

It would like to expose it (msg137071, you should read sigtimedwait, not sigwaitinfo :-)). I started to work on a patch, but it requires a siginfo_t structure, and I didn't finish my patch. I will retry later.

> Expose it as-is, or just add an optional timeout option to sigwait?

I prefer thin wrappers: sigwaitinfo() is more than just a timeout argument, there is also the signal info argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12187>
_______________________________________

From report at bugs.python.org  Thu Jun  9 13:16:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Jun 2011 11:16:31 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <E1QUdDy-0001PN-L0@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2951641faed1 by ?ric Araujo in branch '2.7':
Add examples that work on Windows to distutils docs (#1626300)
http://hg.python.org/cpython/rev/2951641faed1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Thu Jun  9 13:18:05 2011
From: report at bugs.python.org (David Siroky)
Date: Thu, 09 Jun 2011 11:18:05 +0000
Subject: [issue12197] non-blocking SSL write in Windows sends large data but
	raises exception
In-Reply-To: <1306519609.32.0.152577977388.issue12197@psf.upfronthosting.co.za>
Message-ID: <1307618285.39.0.88218782655.issue12197@psf.upfronthosting.co.za>


David Siroky <siroky at dasir.cz> added the comment:

I didn't meant blocking as setblocking(True). I use select/poll but I can't use returned value from send() immediately since in Windows there are often needed more send rounds to actually know how much data was sent.

E.g. in Linux I know it after the first call:

  sslsock.write("abcd") -> returns 2
  poll(sslsock)
  sslsock.write("cd")

in Windows I must do:

  sslsock.write("abcd") -> raises SSLError
  poll(sslsock)
  sslsock.write("abcd") -> returns 4

As I wrote it might be inconsistency in OpenSSL and not in Python's wrapper.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12197>
_______________________________________

From report at bugs.python.org  Thu Jun  9 13:39:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 11:39:57 +0000
Subject: [issue12243] getpass.getuser works on OSX
In-Reply-To: <1307029704.02.0.858553376312.issue12243@psf.upfronthosting.co.za>
Message-ID: <1307619597.13.0.217695103337.issue12243@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

That would be Doc/tools/sphinxext/pyspecific.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12243>
_______________________________________

From report at bugs.python.org  Thu Jun  9 13:45:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 11:45:02 +0000
Subject: [issue11975] Fix referencing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1307619902.25.0.815288748463.issue11975@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t like the idea of built-in functions being displayed as ?builtins.int?: normal use of builtins is without explicit use of the module name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Thu Jun  9 13:46:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 11:46:38 +0000
Subject: [issue12246] Warn when trying to install third-party module from an
	uninstalled checkout
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307619998.29.0.433088003522.issue12246@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great!  I will edit a bit the message and commit this.

----------
stage:  -> commit review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12246>
_______________________________________

From report at bugs.python.org  Thu Jun  9 13:47:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 11:47:52 +0000
Subject: [issue11203] gzip doc is behind
In-Reply-To: <1297539632.81.0.320134391105.issue11203@psf.upfronthosting.co.za>
Message-ID: <1307620072.58.0.113379967878.issue11203@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Just one thing:
> I think the close call needs equal treatment to the open call.

The open call is a module-level functions; the close method of GzipFile cannot be equally treated, as it is in the doc of the class, where no methods are given special treatment :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11203>
_______________________________________

From report at bugs.python.org  Thu Jun  9 13:59:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 11:59:30 +0000
Subject: [issue8927] Handle version incompatibilities in dependencies
In-Reply-To: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>
Message-ID: <1307620770.28.0.386545441927.issue8927@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

[Sridhar]
>> No, it?s register that uploads metadata.
>(was not sent before?)

To me, not to the tracker.

> Ok, that's interesting. Does p7g.install support packages that do not
> register their new releases?
> Setuptools/PIP does by scraping the project home pages.

p7g.pypi.simple uses the screen-scraping PyPI interface called ?simple?, but I don?t know if it goes over to home pages to find links.

> Will p7g.install install 0.8.19?
Try it in a shell?

[Dave]
> I'm sorry, but it is simply not true that this is not a solved
> problem.  This is a well-understood problem that's solved

Well, I?m no researcher but I know that there?s still some research ongoing, in particular for upgrades: http://www.mancoosi.org/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8927>
_______________________________________

From report at bugs.python.org  Thu Jun  9 14:03:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 12:03:26 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1307621006.86.0.977124428772.issue12242@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> One issue is that multiple compiler patterns may match,

Right, we can?t say ?first matches? win if it?s unordered, and we won?t have OrderedDict in all versions supported by distutils2.  Make it a list of tuples.  First match wins, so people will have to write more specific regexes first.

> and break less existing code

That?s not a concern; extensions in setup.cfg are a new thing, and for the Python side, we already break a lot of code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12242>
_______________________________________

From report at bugs.python.org  Thu Jun  9 14:04:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 12:04:25 +0000
Subject: [issue12278] Core mentorship mention in the devguide
In-Reply-To: <1307445407.08.0.276007268612.issue12278@psf.upfronthosting.co.za>
Message-ID: <1307621065.85.0.910363194405.issue12278@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You can just take the descriptions from the mail.python.org page.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12278>
_______________________________________

From report at bugs.python.org  Thu Jun  9 14:06:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 12:06:59 +0000
Subject: [issue10645] Remove egg-info files in stdlib
In-Reply-To: <1291712814.77.0.81787148742.issue10645@psf.upfronthosting.co.za>
Message-ID: <1307621219.72.0.536465186451.issue10645@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +Removing wsgiref.egg-info

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10645>
_______________________________________

From report at bugs.python.org  Thu Jun  9 14:10:26 2011
From: report at bugs.python.org (Ravish)
Date: Thu, 09 Jun 2011 12:10:26 +0000
Subject: [issue12292] bpython
In-Reply-To: <1307621426.23.0.78391837262.issue12292@psf.upfronthosting.co.za>
Message-ID: <1307621426.23.0.78391837262.issue12292@psf.upfronthosting.co.za>


New submission from Ravish <ravish_nayak2003 at yahoo.co.in>:

I was trying to install bpython v0.9.7.1(latest version) on python 2.6.5, it works fine.

But If i try to install on python v3.2 it's behaviour is quite abnormal.

i.e if I  run(bpython) from command prompt, I could able to see the fancy window, but If I try to type something immediately it will show as
"Segmentation fault".

Could you please provide me some suggestion for the above issue.

Thanks,

----------
messages: 137956
nosy: ravish112
priority: normal
severity: normal
status: open
title: bpython
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12292>
_______________________________________

From report at bugs.python.org  Thu Jun  9 14:10:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Jun 2011 12:10:58 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <E1QUe4e-0006Fw-Dy@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 072dbebaa83b by ?ric Araujo in branch '3.2':
Add examples that work on Windows to distutils docs (#1626300)
http://hg.python.org/cpython/rev/072dbebaa83b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Thu Jun  9 14:10:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Jun 2011 12:10:58 +0000
Subject: [issue9312] Fix usage of :option: markup in stdlib ReST docs
In-Reply-To: <1279599587.56.0.337150515932.issue9312@psf.upfronthosting.co.za>
Message-ID: <E1QUe4e-0006Fw-Dr@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 59d785ea0039 by ?ric Araujo in branch '3.2':
Fix a few misuses of :option: I missed in r86521.
http://hg.python.org/cpython/rev/59d785ea0039

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________

From report at bugs.python.org  Thu Jun  9 14:10:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Jun 2011 12:10:59 +0000
Subject: [issue10645] Remove egg-info files in stdlib
In-Reply-To: <1291712814.77.0.81787148742.issue10645@psf.upfronthosting.co.za>
Message-ID: <E1QUe4e-0006Fw-Di@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e3f6c10eb590 by ?ric Araujo in branch 'default':
Stop creating a Python-X.Y.Z-pyX.Y.egg-info file on install (#10645)
http://hg.python.org/cpython/rev/e3f6c10eb590

New changeset af7bc95e5b1e by ?ric Araujo in branch 'default':
The change done for #10645 deserves a NEWS entry
http://hg.python.org/cpython/rev/af7bc95e5b1e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10645>
_______________________________________

From report at bugs.python.org  Thu Jun  9 14:19:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 12:19:19 +0000
Subject: [issue10645] Remove egg-info files in stdlib
In-Reply-To: <1291712814.77.0.81787148742.issue10645@psf.upfronthosting.co.za>
Message-ID: <1307621959.75.0.208946753171.issue10645@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10645>
_______________________________________

From report at bugs.python.org  Thu Jun  9 14:21:31 2011
From: report at bugs.python.org (Fredrik Wendt)
Date: Thu, 09 Jun 2011 12:21:31 +0000
Subject: [issue12293] wrong arguments passed to SMTP.sendmail in example
In-Reply-To: <1307622091.83.0.868143597112.issue12293@psf.upfronthosting.co.za>
Message-ID: <1307622091.83.0.868143597112.issue12293@psf.upfronthosting.co.za>


New submission from Fredrik Wendt <fredrik at wendt.se>:

On http://docs.python.org/library/email-examples.html#email-examples the current example (v2.7.1) at the bottom incorrectly calls SMTP.sendmail() with a single recipient e-mail address. It should be a list of addresses.

----------
assignee: docs at python
components: Documentation
messages: 137960
nosy: docs at python, wendt_se
priority: normal
severity: normal
status: open
title: wrong arguments passed to SMTP.sendmail in example
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12293>
_______________________________________

From report at bugs.python.org  Thu Jun  9 14:27:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Jun 2011 12:27:32 +0000
Subject: [issue9312] Fix usage of :option: markup in stdlib ReST docs
In-Reply-To: <1279599587.56.0.337150515932.issue9312@psf.upfronthosting.co.za>
Message-ID: <E1QUeKg-0007Sh-US@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7164bdfa0b0b by ?ric Araujo in branch '2.7':
Fix a few misuses of :option: I missed in r86521.
http://hg.python.org/cpython/rev/7164bdfa0b0b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________

From report at bugs.python.org  Thu Jun  9 14:27:57 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Thu, 09 Jun 2011 12:27:57 +0000
Subject: [issue12292] bpython
In-Reply-To: <1307621426.23.0.78391837262.issue12292@psf.upfronthosting.co.za>
Message-ID: <1307622477.61.0.0892141954504.issue12292@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

This issue tracker is for reporting issues about Python itself. Issues concerning third-party projects should go to the respective issue tracker of the project first (in this case https://bitbucket.org/bobf/bpython/issues).

This specific issue is caused by issue #9319 and is already fixed. The fix will be included in the next release of Python 3.2. Also, a workaround was added to bpython which will be included in the next release of bpython.

----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12292>
_______________________________________

From report at bugs.python.org  Thu Jun  9 14:28:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 12:28:00 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <1307622480.8.0.0255960834939.issue1626300@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is now fixed in the distutils Installing and Distributing guides.  Does the same problem apply to the new docs using packaging and the pysetup script?  Please check http://docs.python.org/dev/packaging and http://docs.python.org/dev/install

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Thu Jun  9 14:31:26 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Jun 2011 12:31:26 +0000
Subject: [issue12292] bpython
In-Reply-To: <1307621426.23.0.78391837262.issue12292@psf.upfronthosting.co.za>
Message-ID: <1307622686.58.0.983085571713.issue12292@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12292>
_______________________________________

From report at bugs.python.org  Thu Jun  9 14:39:32 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 09 Jun 2011 12:39:32 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1307541119.79.0.601655314785.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110609123922.GA32116@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

@ Ronald Oussoren wrote:
>    if major <= 10:
>       # We're on OSX 10.6 or earlier
>       enableWorkaround()

(You sound as if you participate in an interesting audiophonic
event.  27" imac's are indeed great recording studio hardware.
But no Coffee Shops in California - brrrrr.)
--
Ciao, Steffen
sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Thu Jun  9 15:12:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 13:12:03 +0000
Subject: [issue12282] build process adds CWD (null entry) to PYTHONPATH if
	PYTHONPATH is set in the build environment
In-Reply-To: <1307502658.23.0.460185626535.issue12282@psf.upfronthosting.co.za>
Message-ID: <1307625123.83.0.83928779248.issue12282@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12282>
_______________________________________

From report at bugs.python.org  Thu Jun  9 15:13:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 13:13:08 +0000
Subject: [issue12284] argparse.ArgumentParser: usage example option
In-Reply-To: <1307540382.34.0.477677451975.issue12284@psf.upfronthosting.co.za>
Message-ID: <1307625188.87.0.903929553691.issue12284@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is http://docs.python.org/dev/library/argparse#usage what you want?

----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12284>
_______________________________________

From report at bugs.python.org  Thu Jun  9 15:14:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 13:14:46 +0000
Subject: [issue12293] wrong arguments passed to SMTP.sendmail in example
In-Reply-To: <1307622091.83.0.868143597112.issue12293@psf.upfronthosting.co.za>
Message-ID: <1307625286.19.0.161086998644.issue12293@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: docs at python -> r.david.murray
nosy: +r.david.murray
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12293>
_______________________________________

From report at bugs.python.org  Thu Jun  9 15:49:09 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 09 Jun 2011 13:49:09 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1307627349.56.0.498833450854.issue12291@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I've added a patch which I think fixes marshal.load(), and would be grateful for a review - it's my first C patch for Python. The test_marshal test passes, though I haven't yet added a test for the failing scenario.

----------
keywords: +patch
Added file: http://bugs.python.org/file22290/marshal-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Thu Jun  9 15:52:54 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 09 Jun 2011 13:52:54 +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: <1307627574.15.0.0271682320183.issue11277@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

steffen: I have no idea what you are trying to say in your last message. Could you please try to stay on topic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Thu Jun  9 15:54:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 13:54:18 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1307461733.49.0.987510653631.issue12279@psf.upfronthosting.co.za>
Message-ID: <1307627658.75.0.69122771875.issue12279@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

packaging.command.cmd already has this method: it was renamed to get_reinitialized_function, to better match other method names.

> the workaround of my code is just setting the 'distinfo-dir' option
> with os.curdir value
Yes, that?s a workaround :)  Have you tested writing to build.build_lib (see my previous message)?  The test command for example runs the tests in the build dir, to test what will really get packaged, and to allow build-time 2to3 conversion.

One part of properly implementing a build_distinfo command that can be tricky is the .dist-info/RECORD file.  If you just move the code from install_distinfo, the locations in the RECORD file will not be the actual locations of the files.  Possibilities:
1) don?t generate RECORD at all ? invalid PEP 376
2) generate RECORD with paths to the files in the build dir
3) other?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Thu Jun  9 15:55:09 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Jun 2011 13:55:09 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1307627709.13.0.563500622686.issue12291@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

- Please replace tabs characters by space
- "//" comments are not accepted by some picky C89 compilers

Also, calling f.read(1) for each character may have a large performance impact.  I don't know how this can be solved though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Thu Jun  9 15:59:52 2011
From: report at bugs.python.org (Bugs Fly)
Date: Thu, 09 Jun 2011 13:59:52 +0000
Subject: [issue12294] multiprocessing.Pool: Need a way to find out if work are
	finished.
In-Reply-To: <1307627992.49.0.467043384727.issue12294@psf.upfronthosting.co.za>
Message-ID: <1307627992.49.0.467043384727.issue12294@psf.upfronthosting.co.za>


New submission from Bugs Fly <mozbugbox at yahoo.com.au>:

The join() method of Pool blocks. So it is not good for finding out if there are still running workers once the pool is closed.

There should be a method like is_alive() which don't block, similar to what in Process. Or task_left() which return number of task left.

----------
components: Library (Lib)
messages: 137970
nosy: mozbugbox
priority: normal
severity: normal
status: open
title: multiprocessing.Pool: Need a way to find out if work are finished.
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12294>
_______________________________________

From report at bugs.python.org  Thu Jun  9 16:33:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 14:33:28 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1307630008.37.0.906961368139.issue10224@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> In either case, there's a high likelihood the PYTHON default will
> resolve to 3.3a0 for any Python developer.

Ah, I understand the reason for the phrasing in your patch: UNIX systems typically install 3.x as python3, not python, so the high likelihood is only for Windows and a few UNIX systems like Arch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Thu Jun  9 16:35:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 14:35:32 +0000
Subject: [issue12255] A few changes to .*ignore
In-Reply-To: <1307119345.93.0.971452096543.issue12255@psf.upfronthosting.co.za>
Message-ID: <1307630132.53.0.141712347497.issue12255@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I would also propose to remove *.rej and *.orig from the ignore files.  It?s helpful to see them in hg status in case you had a difficult merge and did not fix all files.  My usage is that I remove *.rej and *.orig after I?m done merging (or checking that the revert is okay).

----------
title: Make VCSes ignore shared libpython -> A few changes to .*ignore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12255>
_______________________________________

From report at bugs.python.org  Thu Jun  9 16:35:54 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 09 Jun 2011 14:35:54 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1307630154.28.0.527723474067.issue12291@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

It should probably be buffered at 512 bytes or some other reasonable number.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Thu Jun  9 16:41:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 14:41:34 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1307630494.07.0.952762267208.issue828450@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I wanted to review the patch but it cannot be applied.  It looks like your third patch applies on top of the second.  Can you generate a full patch?

----------
status: pending -> open
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Thu Jun  9 16:42:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 14:42:16 +0000
Subject: [issue10191] scripts files are not RECORDed.
In-Reply-To: <1288014947.33.0.874343051999.issue10191@psf.upfronthosting.co.za>
Message-ID: <1307630536.65.0.178133219708.issue10191@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I wrote a test but it did not fail.  Can you test it too?

----------
keywords: +patch
versions: +Python 3.3 -3rd party
Added file: http://bugs.python.org/file22291/test-record-scripts-10191.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10191>
_______________________________________

From report at bugs.python.org  Thu Jun  9 16:44:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 14:44:29 +0000
Subject: [issue1083299] Distutils doesn't pick up all the files it should.
Message-ID: <1307630669.6.0.014509441009.issue1083299@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

There are tests for data_files, they are indeed included.  Please reopen if you can reproduce the bug.

----------
resolution:  -> out of date
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1083299>
_______________________________________

From report at bugs.python.org  Thu Jun  9 16:46:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 14:46:33 +0000
Subject: [issue11638] pysetup un sdist crashes with weird trace if version is
	unicode by accident
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1307630793.92.0.833956221718.issue11638@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Python 3.3 works with unicode ;), so we?ll try reproducing this later, when we have the 2.x backport.

----------
assignee: tarek -> eric.araujo
resolution:  -> remind
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Thu Jun  9 16:51:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 14:51:11 +0000
Subject: [issue11028] Implement the setup.py -> setup.cfg in mkcfg
In-Reply-To: <1296139508.67.0.695480903327.issue11028@psf.upfronthosting.co.za>
Message-ID: <1307631071.49.0.939714925048.issue11028@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is now implemented in packaging.create.MainProgram.convert_py_to_cfg.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11028>
_______________________________________

From report at bugs.python.org  Thu Jun  9 16:52:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 14:52:52 +0000
Subject: [issue3992] remove custom log module from distutils2
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1307631172.1.0.129983274241.issue3992@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I?m leaving this open to remind us we want to remove the warn and
> announce methods.  Logging all the way!

Now done.

----------
assignee: tarek -> eric.araujo
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Thu Jun  9 16:52:54 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 09 Jun 2011 14:52:54 +0000
Subject: [issue9284] inspect.findsource() cannot find source for doctest code
In-Reply-To: <1279372617.05.0.528440876901.issue9284@psf.upfronthosting.co.za>
Message-ID: <1307631174.06.0.508964637298.issue9284@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

- First line should be directly after the docstring
- One import per line
- Shouldn't this test be in test_inspect, since that's what you're changing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9284>
_______________________________________

From report at bugs.python.org  Thu Jun  9 16:55:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 14:55:41 +0000
Subject: [issue9395] clean does not remove all temp files
In-Reply-To: <1280311771.86.0.556150594835.issue9395@psf.upfronthosting.co.za>
Message-ID: <1307631341.97.0.553268183892.issue9395@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t remember exactly what I had in mind when I reported this; maybe I didn?t understand the purpose of the clean command, which does not delete all build artifacts but only temporary by-products, unless --all is given.

Jean-Paul, I think I recall that this came from a discussion with you on another bug or on IRC; do you remember something about it?

----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9395>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:00:48 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 09 Jun 2011 15:00:48 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1307631648.96.0.401392938758.issue12291@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +georg.brandl
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:01:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Jun 2011 15:01:24 +0000
Subject: [issue11583] os.path.isdir() is slow on windows
In-Reply-To: <1300354713.42.0.570312056806.issue11583@psf.upfronthosting.co.za>
Message-ID: <E1QUgjb-000468-8m@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d40609dd01e0 by Brian Curtin in branch '3.2':
Correction to 88e318166eaf - Issue #11583
http://hg.python.org/cpython/rev/d40609dd01e0

New changeset fe813f5711a5 by Brian Curtin in branch '2.7':
Correction to f1509fc75435 - Issue #11583
http://hg.python.org/cpython/rev/fe813f5711a5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11583>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:13:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 15:13:39 +0000
Subject: [issue11594] 2to3 does not preserve line endings
In-Reply-To: <1300465648.02.0.83291128633.issue11594@psf.upfronthosting.co.za>
Message-ID: <1307632419.97.0.764758556772.issue11594@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I was surprised to see that the crlf.py file was not using CRLF in the new Mercurial repo.  It is also not in the .hgeol file.  I changed it locally, but it doesn?t change anything, the tests pass before and after the change.

----------
keywords: +patch
versions:  -Python 3.1
Added file: http://bugs.python.org/file22292/2to3-crlf-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11594>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:14:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 15:14:42 +0000
Subject: [issue10510] distutils upload/register should use CRLF in HTTP
	requests
In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za>
Message-ID: <1307632482.06.0.506070756702.issue10510@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
versions: +Python 3.3 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:16:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 15:16:33 +0000
Subject: [issue2057] difflib: add patch capability
In-Reply-To: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>
Message-ID: <1307632593.05.0.886844740455.issue2057@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

For this to move forward, a patch or link to Mercurial repo would be required.

----------
nosy: +eric.araujo
stage: test needed -> needs patch
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2057>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:21:41 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 09 Jun 2011 15:21:41 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1307632901.81.0.807659638008.issue12291@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/issue12291>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:22:39 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 09 Jun 2011 15:22:39 +0000
Subject: [issue11975] Fix referencing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1307632959.19.0.566338739525.issue11975@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Same here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:23:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 15:23:58 +0000
Subject: [issue10086] test_sysconfig failure when prefix matches /site
In-Reply-To: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>
Message-ID: <1307633038.69.0.114452481418.issue10086@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> 1) sysconfig was originally distutils.sysconfig, and some duplication
> remains.  Can?t this bug happen with distutils.sysconfig too?  Should
> we duplicate tests from test_sysconfig to distutils.test_sysconfig?

I?ve looked into it and converting the test to distutils.sysconfig is not trivial: the get_path function is wholly different in distutils, and I?m not even sure it?s possible to get the paths like test_sysconfig does.

> 2) How to prevent a regression?  That is, how to run tests with
> custom ./configure options?

I think I can commit this fix for a minor issue in a test without worrying about regressions.  I manually tested and it?s fixed.

> Anyway, your patch does not catch a similar failure (if this can
> happen):
>   base        = "/site"
>   global_path = "/site-nonsense/..."

If this can?t happen, let us not worry about it :)

----------
title: test_sysconfig failure with site-packages -> test_sysconfig failure when prefix matches /site
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10086>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:24:18 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 09 Jun 2011 15:24:18 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1307633058.54.0.922079247524.issue12291@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sounds blocker-ish enough to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:26:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 15:26:14 +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: <1307633174.1.0.682553353907.issue11591@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Now that site can be imported without side effects under -S, I think the tests could be updated: they don?t have to be all skipped under -S.  See attached patch.

----------
Added file: http://bugs.python.org/file22293/test_site-11591.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11591>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:29:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 15:29:55 +0000
Subject: [issue8617] Better document user site-packages in site module doc
In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>
Message-ID: <1307633395.32.0.334970369206.issue8617@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have started to work on this; I?ll have one or two patches ready in a few weeks.

----------
assignee: docs at python -> eric.araujo
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8617>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:36:39 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Jun 2011 15:36:39 +0000
Subject: [issue12293] wrong arguments passed to SMTP.sendmail in example
In-Reply-To: <1307622091.83.0.868143597112.issue12293@psf.upfronthosting.co.za>
Message-ID: <1307633799.05.0.565027451505.issue12293@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

"The required arguments are an RFC 822 from-address string, a list of RFC 822 to-address strings (a bare string will be treated as a list with 1 address)..."

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12293>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:38:57 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 09 Jun 2011 15:38:57 +0000
Subject: [issue9284] inspect.findsource() cannot find source for doctest code
In-Reply-To: <1279372617.05.0.528440876901.issue9284@psf.upfronthosting.co.za>
Message-ID: <1307633937.38.0.795261379039.issue9284@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

I'm fine with moving the test; I put it in doctest because the inspect behavior we're relying upon here seems somewhat doctest-specific, and the test itself is a doctest. Do you want me to move it? I'll fix up the other things as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9284>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:40:52 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 09 Jun 2011 15:40:52 +0000
Subject: [issue9284] inspect.findsource() cannot find source for doctest code
In-Reply-To: <1307633937.38.0.795261379039.issue9284@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=ENjUMvby5POZaq3iDipXnW-onzA@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/6/9 Dirkjan Ochtman <report at bugs.python.org>:
>
> Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:
>
> I'm fine with moving the test; I put it in doctest because the inspect behavior we're relying upon here seems somewhat doctest-specific, and the test itself is a doctest. Do you want me to move it? I'll fix up the other things as well.

I would prefer that if the bug is somehow reintroduced, test_inspect
instead of test_doctest fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9284>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:42:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 15:42:29 +0000
Subject: [issue12295] Fix ResourceWarning in turtledemo help window
In-Reply-To: <1307634149.19.0.469203775523.issue12295@psf.upfronthosting.co.za>
Message-ID: <1307634149.19.0.469203775523.issue12295@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I found a ResourceWarning while using turtledemo and made this patch to fix it.  It touches idlelib.

----------
assignee: eric.araujo
components: IDLE, Library (Lib)
files: fix-turtledemo-help-resourcewarning.diff
keywords: needs review, patch
messages: 137993
nosy: eric.araujo
priority: normal
severity: normal
stage: patch review
status: open
title: Fix ResourceWarning in turtledemo help window
versions: Python 3.2
Added file: http://bugs.python.org/file22294/fix-turtledemo-help-resourcewarning.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12295>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:45:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 15:45:27 +0000
Subject: [issue12296] Minor clarification in devguide
In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>
Message-ID: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I found the wording of one line of the devguide strange and changed it IMO for the better.  Please review.

----------
assignee: eric.araujo
components: Devguide
files: clarify-bwcompat-devguide.diff
keywords: needs review, patch
messages: 137994
nosy: eric.araujo
priority: normal
severity: normal
stage: patch review
status: open
title: Minor clarification in devguide
versions: 3rd party
Added file: http://bugs.python.org/file22295/clarify-bwcompat-devguide.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12296>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:49:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 15:49:11 +0000
Subject: [issue12297] Clarifications to atexit.register and unregister doc
In-Reply-To: <1307634551.41.0.658857259056.issue12297@psf.upfronthosting.co.za>
Message-ID: <1307634551.41.0.658857259056.issue12297@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I wanted to know the behavior of atexit.register with the same function added more than once and found out it is not explicitly documented.  I experimented and made a patch to the doc.

----------
assignee: eric.araujo
components: Documentation
files: atexit-doc.diff
keywords: patch
messages: 137995
nosy: eric.araujo
priority: normal
severity: normal
stage: patch review
status: open
title: Clarifications to atexit.register and unregister doc
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22296/atexit-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12297>
_______________________________________

From report at bugs.python.org  Thu Jun  9 17:55:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Jun 2011 15:55:35 +0000
Subject: [issue12168] SysLogHandler incorrectly appends \000 to messages
In-Reply-To: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>
Message-ID: <E1QUha1-0000ek-Mr@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 260b84851d1f by Vinay Sajip in branch '3.2':
Issue #12168: SysLogHandler now allows NUL termination to be controlled using a new 'append_nul' attribute on the handler.
http://hg.python.org/cpython/rev/260b84851d1f

New changeset ac1217099b3f by Vinay Sajip in branch 'default':
Merged fix for issue #12168 from 3.2.
http://hg.python.org/cpython/rev/ac1217099b3f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12168>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:06:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 16:06:52 +0000
Subject: [issue12298] Sphinx glitch in library/functions
In-Reply-To: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za>
Message-ID: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

In the summary table at the top of library/functions, the links for frozenset and memoryview do not jump to the definition down in the same file, but link to stdtypes.

----------
assignee: docs at python
components: Documentation
messages: 137997
nosy: docs at python, eric.araujo, ezio.melotti
priority: normal
severity: normal
status: open
title: Sphinx glitch in library/functions
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12298>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:10:12 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 09 Jun 2011 16:10:12 +0000
Subject: [issue2057] difflib: add patch capability
In-Reply-To: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>
Message-ID: <1307635812.32.0.576779776299.issue2057@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

For this to move forward, PSF should accelerate work on new sane Contributor's Agreements or join Harmony (http://www.harmonyagreements.org/)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2057>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:11:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 16:11:27 +0000
Subject: [issue7015] Getting call trace while executing "modules spam" at help
	prompt
In-Reply-To: <1254206290.75.0.617783726921.issue7015@psf.upfronthosting.co.za>
Message-ID: <1307635887.94.0.312412033621.issue7015@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks like this is an external bug.

----------
nosy: +eric.araujo
resolution:  -> invalid
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7015>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:12:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 16:12:09 +0000
Subject: [issue8488] Docstrings of non-data descriptors "ignored"
In-Reply-To: <1271874309.07.0.567011993617.issue8488@psf.upfronthosting.co.za>
Message-ID: <1307635929.44.0.830513880672.issue8488@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8488>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:12:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 16:12:52 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1307635972.22.0.864602178336.issue10446@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can I help moving this forward?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:17:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 16:17:50 +0000
Subject: [issue12299] Stop documenting functions added by site as builtins
In-Reply-To: <1307636270.04.0.997555638345.issue12299@psf.upfronthosting.co.za>
Message-ID: <1307636270.04.0.997555638345.issue12299@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I find it harmful that exit, quit and help are documented in library/functions instead of library/constants (under the section ?constants added by the site module?).  It leads people to use unqualified help or exit instead of pydoc.help or sys.exit, and that would break under -S.  I?d like to move the doc for these functions (and add a link from l/functions to l/constants).

----------
assignee: eric.araujo
components: Documentation
messages: 138001
nosy: eric.araujo
priority: normal
severity: normal
status: open
title: Stop documenting functions added by site as builtins
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12299>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:19:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 16:19:00 +0000
Subject: [issue12300] Document pydoc.help
In-Reply-To: <1307636340.19.0.379742788124.issue12300@psf.upfronthosting.co.za>
Message-ID: <1307636340.19.0.379742788124.issue12300@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

The only public function in pydoc is help, and it?s not listed in the module docs.  The existing doc in library/functions could be moved to library/pydoc.  See also #12299.

----------
assignee: docs at python
components: Documentation
messages: 138002
nosy: docs at python, eric.araujo
priority: normal
severity: normal
status: open
title: Document pydoc.help
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12300>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:21:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 16:21:02 +0000
Subject: [issue7283] test_site failure when .local/lib/pythonX.Y/site-packages
	hasn't been created yet
In-Reply-To: <1257640034.65.0.139323856655.issue7283@psf.upfronthosting.co.za>
Message-ID: <1307636462.35.0.730505479974.issue7283@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Related: I found that test_site tries to create the user site-packages dir if it does not exist, but it does not remove it after the test run.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7283>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:22:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jun 2011 16:22:29 +0000
Subject: [issue12301] Use :data:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

In a great number of files, the ``code`` markup is used instead of the :data: role, which would create a link to the appropriate definition.

Unless someone objects, I would like to change all of them.

----------
assignee: eric.araujo
components: Documentation
messages: 138004
nosy: eric.araujo
priority: normal
severity: normal
status: open
title: Use :data:`sys.thing` instead of ``sys.thing`` throughout
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12301>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:23:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 09 Jun 2011 16:23:21 +0000
Subject: [issue12301] Use :data:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1307636601.04.0.551399583068.issue12301@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/issue12301>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:24:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 09 Jun 2011 16:24:27 +0000
Subject: [issue12298] Sphinx glitch in library/functions
In-Reply-To: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za>
Message-ID: <1307636667.93.0.806892661863.issue12298@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
dependencies: +Fix referencing of built-in types (list, int, ...)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12298>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:26:07 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 09 Jun 2011 16:26:07 +0000
Subject: [issue12298] Sphinx glitch in library/functions
In-Reply-To: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za>
Message-ID: <1307636767.73.0.655005225708.issue12298@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is not a Sphinx glitch: that's where these classes are defined.

(Plus, dependencies work the other way round.)

----------
dependencies:  -Fix referencing of built-in types (list, int, ...)
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12298>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:26:40 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 09 Jun 2011 16:26:40 +0000
Subject: [issue12298] Sphinx glitch in library/functions
In-Reply-To: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za>
Message-ID: <1307636800.99.0.0436705691512.issue12298@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12298>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:27:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 09 Jun 2011 16:27:41 +0000
Subject: [issue11975] Fix referencing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1307636861.15.0.731754605634.issue11975@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It won't (because there's the ~ in :func/class:`~__builtin__.int`).  Specifying the module would just be a workaround used to distinguish the 'int' in functions.rst from the one in stdtypes.rst.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:29:55 2011
From: report at bugs.python.org (Jonas H.)
Date: Thu, 09 Jun 2011 16:29:55 +0000
Subject: [issue12284] argparse.ArgumentParser: usage example option
In-Reply-To: <1307540382.34.0.477677451975.issue12284@psf.upfronthosting.co.za>
Message-ID: <1307636995.94.0.497939782672.issue12284@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

Nope. I want an "examples" section, for example from `man git log`:


EXAMPLES
       git log --no-merges
           Show the whole commit history, but skip any merges

       git log v2.6.12.. include/scsi drivers/scsi
           Show all commits since version v2.6.12 that changed any file in the include/scsi or drivers/scsi subdirectories

       ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12284>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:30:44 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 09 Jun 2011 16:30:44 +0000
Subject: [issue12284] argparse.ArgumentParser: usage example option
In-Reply-To: <1307540382.34.0.477677451975.issue12284@psf.upfronthosting.co.za>
Message-ID: <1307637044.3.0.506142610974.issue12284@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/issue12284>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:30:51 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 09 Jun 2011 16:30:51 +0000
Subject: [issue9284] inspect.findsource() cannot find source for doctest code
In-Reply-To: <1279372617.05.0.528440876901.issue9284@psf.upfronthosting.co.za>
Message-ID: <1307637051.71.0.566994796842.issue9284@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Here's a fresh patch.

----------
Added file: http://bugs.python.org/file22297/issue9284.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9284>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:31:05 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 09 Jun 2011 16:31:05 +0000
Subject: [issue9284] inspect.findsource() cannot find source for doctest code
In-Reply-To: <1279372617.05.0.528440876901.issue9284@psf.upfronthosting.co.za>
Message-ID: <1307637065.37.0.933404876535.issue9284@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


Removed file: http://bugs.python.org/file22270/issue9284.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9284>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:34:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Jun 2011 16:34:43 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <E1QUiBt-0003kz-L4@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset cab204a79e09 by R David Murray in branch 'default':
#10424: argument names are now included in the missing argument message
http://hg.python.org/cpython/rev/cab204a79e09

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:36:19 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Jun 2011 16:36:19 +0000
Subject: [issue2057] difflib: add patch capability
In-Reply-To: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>
Message-ID: <1307637379.7.0.404911617739.issue2057@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Anatoly,
Even if I remove all sarcasm from your previous answer, I don't see what it brings to the current issue.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2057>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:36:30 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 09 Jun 2011 16:36:30 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1307637390.79.0.756805208673.issue12291@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

@Amaury: Re formatting and comment style - I will address this. The diff I posted is to the default branch rather than 3.2, though it won't change the main substance of the patch.

Re. performance and buffering: I agree this could have an impact (although strings are not actually read a byte at a time), but it's not easy to address because even if you e.g. wrapped the incoming stream with a BufferedReader, you have nowhere to keep the resulting instance in between multiple calls to marshal.load() from external code.

For best performance ISTM you'd have to implement your own buffering - but surely this is to be avoided? It can't be the only place where you need good I/O performance from file-like objects. A quick scan of the pickle module didn't show me anything I could easily use, and a key difference from pickle is that you don't have a corresponding "Unmarshaller" object which could hold the state that an Unpickler does, and which would be needed to hold the buffering state.

Of course one could implement limited buffering, i.e. for just the duration of a single marshal.load() call, but perhaps this could be done as a later step after evaluating the actual performance of this implementation. Having something that works correctly, albeit slowly, is better than having the current situation ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:36:46 2011
From: report at bugs.python.org (Erik Bray)
Date: Thu, 09 Jun 2011 16:36:46 +0000
Subject: [issue11595] Miscellaneous bugs in cfg_to_args() utility function
In-Reply-To: <1300466317.84.0.72161184259.issue11595@psf.upfronthosting.co.za>
Message-ID: <1307637406.91.0.693070434908.issue11595@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

Thanks Eric for your review.  Obviously the last patch was rushed, and I didn't even run the tests.  It also got my changes for issue12240 mixed into it.  So I've gone ahead and attached an updated patch which incorporates your review comments.

----------
Added file: http://bugs.python.org/file22298/issue11595-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11595>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:38:26 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Jun 2011 16:38:26 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1307637506.64.0.656352265964.issue10424@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

With input from Michele on IRC I updated the tests to be more generic (not depend on the order of the reported argument names) and moved the test I talked about in my last message into a third unit test.

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Thu Jun  9 18:47:51 2011
From: report at bugs.python.org (Erik Bray)
Date: Thu, 09 Jun 2011 16:47:51 +0000
Subject: [issue12240] Allow multiple setup_hooks
In-Reply-To: <1307026779.27.0.653754848212.issue12240@psf.upfronthosting.co.za>
Message-ID: <1307638071.67.0.428305480447.issue12240@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

Here's an update with tests.  It should be applied after my patch for issue11595.

----------
Added file: http://bugs.python.org/file22299/python_issue12240-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12240>
_______________________________________

From report at bugs.python.org  Thu Jun  9 19:06:27 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 09 Jun 2011 17:06:27 +0000
Subject: [issue10897] UNIX mmap unnecessarily dup() file descriptor
In-Reply-To: <1294845379.76.0.427887707002.issue10897@psf.upfronthosting.co.za>
Message-ID: <1307639187.61.0.558620631315.issue10897@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Trying to revive this issue.
I'm +1 on this change: duping the file descriptor is definitely unexpected and has some side effects.
I think we should remove the call to dup and close, it's really the user's responsibility to avoid closing the FD.
If the FD is closed when mmap_resize is called, ftruncate will fail with EBADF, without harm.
The real problem is more if the file has been closed and another one got open, with the same FD.
If we wanted to be paranoid and avoid truncating/re-mapping another file, we could store the struct stat's st_ino field when the mapping is created, and re-check its value in mmap_resize (and if we wanted to be really paranoid we could also store st_dev, because inodes are unique only within a given file system).

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10897>
_______________________________________

From report at bugs.python.org  Thu Jun  9 19:17:21 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 09 Jun 2011 17:17:21 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1307615622.95.0.282461039492.issue8407@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=kj+3M1f4=1adWHEQwHFA_SMm+fA@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

I just noticed something "funny": signal_sigwait doesn't release the
GIL, which means that it's pretty much useless :-)
Patch attached.
Also, test_sigwait doesn't block the signal before calling sigwait: it
happens to work because there's only one thread, but it's undefined
behaviour.

----------
Added file: http://bugs.python.org/file22300/sigwait_gil.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________
-------------- next part --------------
--- cpython-302424b84b07/Modules/signalmodule.c	2011-06-01 02:39:38.000000000 +0000
+++ cpython/Modules/signalmodule.c	2011-06-09 11:39:28.000000000 +0000
@@ -662,7 +662,9 @@
     if (iterable_to_sigset(signals, &set))
         return NULL;
 
+    Py_BEGIN_ALLOW_THREADS
     err = sigwait(&set, &signum);
+    Py_END_ALLOW_THREADS
     if (err) {
         errno = err;
         return PyErr_SetFromErrno(PyExc_OSError);

From report at bugs.python.org  Thu Jun  9 19:20:12 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 09 Jun 2011 17:20:12 +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: <1307640012.08.0.491605497744.issue8407@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

This whole thread is becoming quite confusing.
It would be better to open a separate issue for any bug or feature request which is not related to "exposing signalfd(2) and pthread_sigmask".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Thu Jun  9 19:38:19 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 09 Jun 2011 17:38:19 +0000
Subject: [issue12168] SysLogHandler incorrectly appends \000 to messages
In-Reply-To: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>
Message-ID: <1307641099.11.0.616066845101.issue12168@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/issue12168>
_______________________________________

From report at bugs.python.org  Thu Jun  9 20:05:29 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 09 Jun 2011 18:05:29 +0000
Subject: [issue2057] difflib: add patch capability
In-Reply-To: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>
Message-ID: <1307642729.1.0.587422796329.issue2057@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

It is not sarcasm, but prerequisite. I do not sign papers I don't understand or papers that doesn't make any sense (and thus are free to any interpretation). I could sign current CLA right away, but I prefer not to do this until everybody is aware of the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2057>
_______________________________________

From report at bugs.python.org  Thu Jun  9 20:13:23 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 09 Jun 2011 18:13:23 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307569986.96.0.534178412085.issue12287@psf.upfronthosting.co.za>
Message-ID: <BANLkTinr_0hANceEV8mUJCVLp6kU7GnqBA@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

> You don't check that 0 <= fd (e.g. oss.close()).
>

Actually, none of ossaudiodev's method does...

This makes it even easier to trigger a segfault (at least on RHEL4):
"""
import ossaudiodev

o = ossaudiodev.open('/dev/dsp', 'w')
o.close()
o.writeall(b'toto')
"""

I've attached a patch to fix that (check that the underlying FD isn't closed).

> The select has a specific code for Visual Studio (don't check v < FD_SETSIZE):

> Python has a _PyVerify_fd() function. We might write a similar function/macro to check if a file descriptor can be used in a file descriptor set. FD_SET() is used in the oss, readline, socket and _ssl modules. The socket module has a IS_SELECTABLE() macro:

So, this _PyCheckSelectable_fd ? function/macro would:
- return true (1) on Visual Studio or if
Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE is defined
- return false (0) if the file descriptor is greater than FD_SETSIZE otherwise
Do we agree on that?
Where should I add it? selectmodule, posixmodule, somewhere else?

>
> Note: do you really use the OSS module? On which OS? :)
>

Well, while we don't use ossaudiodev, we have a couple hundred Linux
machines at work, and we use OSS on Linux 2.6.9 kernels (and Python
2.3.4 ;-) )

----------
Added file: http://bugs.python.org/file22301/oss_check_closed.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________
-------------- next part --------------
diff -r 964d0d65a2a9 Lib/test/test_ossaudiodev.py
--- a/Lib/test/test_ossaudiodev.py	Wed Jun 08 19:18:14 2011 +0200
+++ b/Lib/test/test_ossaudiodev.py	Thu Jun 09 20:08:30 2011 +0200
@@ -170,6 +170,14 @@
             pass
         self.assertTrue(dsp.closed)
 
+    def test_on_closed(self):
+        dsp = ossaudiodev.open('w')
+        dsp.close()
+        self.assertRaises(ValueError, dsp.fileno)
+        self.assertRaises(ValueError, dsp.read, 1)
+        self.assertRaises(ValueError, dsp.write, b'x')
+        self.assertRaises(ValueError, dsp.writeall, b'x')
+
 
 def test_main():
     try:
diff -r 964d0d65a2a9 Modules/ossaudiodev.c
--- a/Modules/ossaudiodev.c	Wed Jun 08 19:18:14 2011 +0200
+++ b/Modules/ossaudiodev.c	Thu Jun 09 20:08:30 2011 +0200
@@ -213,6 +213,20 @@
  * Helper functions
  */
 
+/* Check if a given file descriptor is valid (i.e. hasn't been closed).
+ * If true, return 1. Otherwise, raise ValueError and return 0.
+ */
+static int _check_fd_valid(int fd)
+{
+    if (fd >= 0) {
+        return 1;
+    } else {
+        PyErr_SetString(PyExc_ValueError,
+                        "Operation on closed file descriptor");
+        return 0;
+    }
+}
+
 /* _do_ioctl_1() is a private helper function used for the OSS ioctls --
    SNDCTL_DSP_{SETFMT,CHANNELS,SPEED} -- that that are called from C
    like this:
@@ -300,6 +314,9 @@
 static PyObject *
 oss_nonblock(oss_audio_t *self, PyObject *unused)
 {
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     /* Hmmm: it doesn't appear to be possible to return to blocking
        mode once we're in non-blocking mode! */
     if (ioctl(self->fd, SNDCTL_DSP_NONBLOCK, NULL) == -1)
@@ -311,6 +328,9 @@
 static PyObject *
 oss_setfmt(oss_audio_t *self, PyObject *args)
 {
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_1(self->fd, args, "setfmt", SNDCTL_DSP_SETFMT);
 }
 
@@ -318,6 +338,10 @@
 oss_getfmts(oss_audio_t *self, PyObject *unused)
 {
     int mask;
+
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     if (ioctl(self->fd, SNDCTL_DSP_GETFMTS, &mask) == -1)
         return PyErr_SetFromErrno(PyExc_IOError);
     return PyLong_FromLong(mask);
@@ -326,30 +350,45 @@
 static PyObject *
 oss_channels(oss_audio_t *self, PyObject *args)
 {
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_1(self->fd, args, "channels", SNDCTL_DSP_CHANNELS);
 }
 
 static PyObject *
 oss_speed(oss_audio_t *self, PyObject *args)
 {
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_1(self->fd, args, "speed", SNDCTL_DSP_SPEED);
 }
 
 static PyObject *
 oss_sync(oss_audio_t *self, PyObject *args)
 {
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_0(self->fd, args, "sync", SNDCTL_DSP_SYNC);
 }
 
 static PyObject *
 oss_reset(oss_audio_t *self, PyObject *args)
 {
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_0(self->fd, args, "reset", SNDCTL_DSP_RESET);
 }
 
 static PyObject *
 oss_post(oss_audio_t *self, PyObject *args)
 {
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_0(self->fd, args, "post", SNDCTL_DSP_POST);
 }
 
@@ -364,6 +403,9 @@
     char *cp;
     PyObject *rv;
 
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     if (!PyArg_ParseTuple(args, "i:read", &size))
         return NULL;
     rv = PyBytes_FromStringAndSize(NULL, size);
@@ -391,6 +433,9 @@
     char *cp;
     int rv, size;
 
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     if (!PyArg_ParseTuple(args, "y#:write", &cp, &size)) {
         return NULL;
     }
@@ -422,6 +467,9 @@
        mode, the behaviour of write() and writeall() from Python is
        indistinguishable. */
 
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     if (!PyArg_ParseTuple(args, "y#:write", &cp, &size))
         return NULL;
 
@@ -489,6 +537,9 @@
 static PyObject *
 oss_fileno(oss_audio_t *self, PyObject *unused)
 {
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     return PyLong_FromLong(self->fd);
 }
 
@@ -503,6 +554,9 @@
     int fmt, channels, rate;
     PyObject * rv;                    /* return tuple (fmt, channels, rate) */
 
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     if (!PyArg_ParseTuple(args, "iii|i:setparameters",
                           &wanted_fmt, &wanted_channels, &wanted_rate,
                           &strict))
@@ -593,6 +647,9 @@
     audio_buf_info ai;
     int nchannels=0, ssize=0;
 
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     if (_ssize(self, &nchannels, &ssize) < 0 || !nchannels || !ssize) {
         PyErr_SetFromErrno(PyExc_IOError);
         return NULL;
@@ -612,6 +669,9 @@
     audio_buf_info ai;
     int nchannels=0, ssize=0;
 
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     if (_ssize(self, &nchannels, &ssize) < 0 || !nchannels || !ssize) {
         PyErr_SetFromErrno(PyExc_IOError);
         return NULL;
@@ -632,6 +692,9 @@
     audio_buf_info ai;
     int nchannels=0, ssize=0;
 
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     if (_ssize(self, &nchannels, &ssize) < 0 || !nchannels || !ssize) {
         PyErr_SetFromErrno(PyExc_IOError);
         return NULL;
@@ -649,6 +712,9 @@
     count_info info;
     int req;
 
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     if (self->mode == O_RDONLY)
         req = SNDCTL_DSP_GETIPTR;
     else
@@ -679,6 +745,9 @@
 static PyObject *
 oss_mixer_fileno(oss_mixer_t *self, PyObject *unused)
 {
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     return PyLong_FromLong(self->fd);
 }
 
@@ -687,6 +756,9 @@
 static PyObject *
 oss_mixer_controls(oss_mixer_t *self, PyObject *args)
 {
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_1_internal(self->fd, args, "controls",
         SOUND_MIXER_READ_DEVMASK);
 }
@@ -694,6 +766,9 @@
 static PyObject *
 oss_mixer_stereocontrols(oss_mixer_t *self, PyObject *args)
 {
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_1_internal(self->fd, args, "stereocontrols",
         SOUND_MIXER_READ_STEREODEVS);
 }
@@ -701,6 +776,9 @@
 static PyObject *
 oss_mixer_reccontrols(oss_mixer_t *self, PyObject *args)
 {
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_1_internal(self->fd, args, "reccontrols",
         SOUND_MIXER_READ_RECMASK);
 }
@@ -710,6 +788,9 @@
 {
     int channel, volume;
 
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     /* Can't use _do_ioctl_1 because of encoded arg thingy. */
     if (!PyArg_ParseTuple(args, "i:get", &channel))
         return NULL;
@@ -730,6 +811,9 @@
 {
     int channel, volume, leftVol, rightVol;
 
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     /* Can't use _do_ioctl_1 because of encoded arg thingy. */
     if (!PyArg_ParseTuple(args, "i(ii):set", &channel, &leftVol, &rightVol))
         return NULL;
@@ -755,6 +839,9 @@
 static PyObject *
 oss_mixer_get_recsrc(oss_mixer_t *self, PyObject *args)
 {
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_1_internal(self->fd, args, "get_recsrc",
         SOUND_MIXER_READ_RECSRC);
 }
@@ -762,6 +849,9 @@
 static PyObject *
 oss_mixer_set_recsrc(oss_mixer_t *self, PyObject *args)
 {
+    if (!_check_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_1(self->fd, args, "set_recsrc",
         SOUND_MIXER_WRITE_RECSRC);
 }

From report at bugs.python.org  Thu Jun  9 21:21:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Jun 2011 19:21:50 +0000
Subject: [issue12283] python3.2 smtplib _quote_periods
In-Reply-To: <1307529152.41.0.398489022746.issue12283@psf.upfronthosting.co.za>
Message-ID: <E1QUknd-0001GO-AD@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 077b016e4a6d by R David Murray in branch '3.2':
#12283: Fixed regression in smtplib quoting of leading dots in DATA.
http://hg.python.org/cpython/rev/077b016e4a6d

New changeset cedceeb45030 by R David Murray in branch 'default':
merge #12283: Fixed regression in smtplib quoting of leading dots in DATA.
http://hg.python.org/cpython/rev/cedceeb45030

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12283>
_______________________________________

From report at bugs.python.org  Thu Jun  9 21:25:06 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Jun 2011 19:25:06 +0000
Subject: [issue12283] python3.2 smtplib _quote_periods
In-Reply-To: <1307529152.41.0.398489022746.issue12283@psf.upfronthosting.co.za>
Message-ID: <1307647506.01.0.01933646791.issue12283@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for the report.  I broke that when I refactored the code, and unfortunately there was no existing test that tested dot quoting.  There is now.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12283>
_______________________________________

From report at bugs.python.org  Thu Jun  9 21:48:24 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 09 Jun 2011 19:48:24 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307648904.8.0.156789845487.issue12248@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Raymond, I like your patch and I think it addresses the issue nicely.  I made one small change, which is to add a test for non-list-sequenceness instead of changing the existing __dir__is_list test.  I think both tests are useful to keep.

Benjamin, what do you think about this for 2.7.2?

----------
Added file: http://bugs.python.org/file22302/12248.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12248>
_______________________________________

From report at bugs.python.org  Thu Jun  9 21:50:07 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 09 Jun 2011 19:50:07 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1307649007.96.0.413872087946.issue12291@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Another thought about buffering, which might be a bit of a show-stopper: if in a particular load() call we read ahead for buffering purposes, we've altered the underlying stream (which might not be seekable to allow position restoring). The next call to load() will be likely to fail, since the underlying stream has been positioned further than expected by the earlier load() call, and the buffer state has been lost. Not sure how easy it is to get around this ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Thu Jun  9 22:02:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Jun 2011 20:02:08 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <E1QUlQc-0004hn-GW@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7530b141c20f by R David Murray in branch '3.2':
#10694: zipfile now ignores garbage at the end of a zipfile.
http://hg.python.org/cpython/rev/7530b141c20f

New changeset 2e49722c7263 by R David Murray in branch 'default':
Merge #10694: zipfile now ignores garbage at the end of a zipfile.
http://hg.python.org/cpython/rev/2e49722c7263

New changeset cc3255a707c7 by R David Murray in branch '2.7':
#10694: zipfile now ignores garbage at the end of a zipfile.
http://hg.python.org/cpython/rev/cc3255a707c7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Thu Jun  9 22:04:10 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Jun 2011 20:04:10 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1307649850.77.0.43373033918.issue10694@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

While I don't understand the zip file structure enough to do a definitive review of the patch, I'm willing to take processing 50K zip files successfully as a definitive test :)

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Thu Jun  9 22:09:24 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Jun 2011 20:09:24 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1307650164.84.0.157620470547.issue1757072@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that based on the fact that most zipfile tools handle garbage after the indicated end of the comment by ignoring it, #10694 fixed zipfile to also ignore such trailing data.

It sounds like there may be more out-of-spec errors that could be ignored, though.  Should this issue therefore be left open?  If so, does anyone want to propose a patch?

----------
nosy: +r.david.murray
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757072>
_______________________________________

From report at bugs.python.org  Thu Jun  9 22:55:34 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 09 Jun 2011 20:55:34 +0000
Subject: [issue9344] please add posix.getgrouplist()
In-Reply-To: <1279890657.77.0.804697326433.issue9344@psf.upfronthosting.co.za>
Message-ID: <1307652934.68.0.59035330822.issue9344@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I haven't tested yet, but feel free to commit and I'll fix any OSX issues later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9344>
_______________________________________

From report at bugs.python.org  Thu Jun  9 23:22:15 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 09 Jun 2011 21:22:15 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1307654535.76.0.52525810893.issue7652@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Removed file: http://bugs.python.org/file15854/py3k_help_unify.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Thu Jun  9 23:22:19 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 09 Jun 2011 21:22:19 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1307654539.99.0.58456118835.issue7652@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Removed file: http://bugs.python.org/file15855/trunk_help_unify.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Thu Jun  9 23:45:27 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 09 Jun 2011 21:45:27 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1307655927.86.0.219486995491.issue7652@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
hgrepos: +25

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Thu Jun  9 23:48:24 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 09 Jun 2011 21:48:24 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1307656104.44.0.666500003721.issue7652@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file22303/ad05c2fdb3b2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Thu Jun  9 23:51:39 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 09 Jun 2011 21:51:39 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1307656299.18.0.601111857024.issue7652@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Removed file: http://bugs.python.org/file22303/ad05c2fdb3b2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Fri Jun 10 00:13:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 09 Jun 2011 22:13:45 +0000
Subject: [issue11375] urllib2 over SOCKS doesn't use proxy for DNS
In-Reply-To: <1299077508.41.0.756366246736.issue11375@psf.upfronthosting.co.za>
Message-ID: <1307657625.93.0.00667888629626.issue11375@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11375>
_______________________________________

From report at bugs.python.org  Fri Jun 10 00:23:30 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 09 Jun 2011 22:23:30 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1307658210.33.0.767899192753.issue7652@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file22304/9a10e3232445.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Fri Jun 10 00:29:13 2011
From: report at bugs.python.org (Michael Mulich)
Date: Thu, 09 Jun 2011 22:29:13 +0000
Subject: [issue8371] Add a command to download distributions
In-Reply-To: <1271004631.29.0.0742687502668.issue8371@psf.upfronthosting.co.za>
Message-ID: <1307658553.8.0.820990667352.issue8371@psf.upfronthosting.co.za>


Changes by Michael Mulich <michael.mulich at gmail.com>:


----------
nosy: +michael.mulich

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8371>
_______________________________________

From report at bugs.python.org  Fri Jun 10 00:31:06 2011
From: report at bugs.python.org (Michael Mulich)
Date: Thu, 09 Jun 2011 22:31:06 +0000
Subject: [issue8501] --dry-run option doesn't work
In-Reply-To: <1271972145.51.0.00309332974734.issue8501@psf.upfronthosting.co.za>
Message-ID: <1307658666.51.0.887143043297.issue8501@psf.upfronthosting.co.za>


Changes by Michael Mulich <michael.mulich at gmail.com>:


----------
nosy: +michael.mulich

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8501>
_______________________________________

From report at bugs.python.org  Fri Jun 10 00:34:07 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 09 Jun 2011 22:34:07 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1307658847.26.0.567901846334.issue7652@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Just a couple of remarks about the diff I created:

The changes to decimal.py are exploratory (i.e. done quite hastily)
and serve the purpose to fulfill PEP-399.

library/cdecimal.rst is completely out of date.


The rest should be very stable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Fri Jun 10 00:38:56 2011
From: report at bugs.python.org (Michael Mulich)
Date: Thu, 09 Jun 2011 22:38:56 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1307659136.84.0.584820218324.issue8591@psf.upfronthosting.co.za>


Changes by Michael Mulich <michael.mulich at gmail.com>:


----------
nosy: +michael.mulich

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8591>
_______________________________________

From report at bugs.python.org  Fri Jun 10 00:40:27 2011
From: report at bugs.python.org (Michael Mulich)
Date: Thu, 09 Jun 2011 22:40:27 +0000
Subject: [issue11880] add a {dist-info} category to distutils2
In-Reply-To: <1303231865.42.0.936595329467.issue11880@psf.upfronthosting.co.za>
Message-ID: <1307659227.58.0.495015633542.issue11880@psf.upfronthosting.co.za>


Changes by Michael Mulich <michael.mulich at gmail.com>:


----------
nosy: +michael.mulich

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11880>
_______________________________________

From report at bugs.python.org  Fri Jun 10 00:41:24 2011
From: report at bugs.python.org (Michael Mulich)
Date: Thu, 09 Jun 2011 22:41:24 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1307659284.09.0.159833967065.issue8668@psf.upfronthosting.co.za>


Changes by Michael Mulich <michael.mulich at gmail.com>:


----------
nosy: +michael.mulich

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Fri Jun 10 00:43:40 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 09 Jun 2011 22:43:40 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307648904.8.0.156789845487.issue12248@psf.upfronthosting.co.za>
Message-ID: <BANLkTinH1m_zfQF1b8JNETx0RYDVzW=fnw@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/6/9 Barry A. Warsaw <report at bugs.python.org>:
>
> Barry A. Warsaw <barry at python.org> added the comment:
>
> Raymond, I like your patch and I think it addresses the issue nicely. ?I made one small change, which is to add a test for non-list-sequenceness instead of changing the existing __dir__is_list test. ?I think both tests are useful to keep.
>
> Benjamin, what do you think about this for 2.7.2?

My preference is to leave 2.7 alone (actually all maintenance
releases) and apply the patch to 3.3. It seems to me the type
restricts are tangentially only related to the issue. There's no need
to change the behavior for new-style classes, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12248>
_______________________________________

From report at bugs.python.org  Fri Jun 10 00:53:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jun 2011 22:53:10 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <BANLkTinr_0hANceEV8mUJCVLp6kU7GnqBA@mail.gmail.com>
Message-ID: <1307659980.25903.23.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> So, this _PyCheckSelectable_fd ? function/macro would:
> - return true (1) on Visual Studio or if
> Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE is defined
> - return false (0) if the file descriptor is greater than FD_SETSIZE otherwise
> Do we agree on that?

Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE is specific to Windows.

/* WinSock does not use a bitmask in select, and uses
   socket handles greater than FD_SETSIZE */
#define Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE

I don't understand if socket file descriptors are different than
(classic) file descriptors.

socketmodule.c uses Py_SAFE_DOWNCAST(s->sock_fd+1, SOCKET_T, int), which
means that the socket type can be different (bigger) than int.

"#if defined(_MSC_VER)" is maybe redundant with
Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE (with "#ifdef MS_WINDOWS" ?).

Does other compilers, like Cygwin / MinGW, also use WinSock?

> Where should I add it? selectmodule, posixmodule, somewhere else?

_Py_Verify_fd() is defined in posixmodule.c and fileobject.h.

If you would like write a _PyCheckSelectable_fd() function/macro, it can
be defined in fileobject.h, and implemented anymore. selectmodule.c is
maybe a better choice than posixmodule.c because posixmodule.c doesn't
use select. Or maybe in socketmodule.c if you reuse IS_SELECTABLE code.

For the name, I would prefer _PyIsSelectable_fd(). With "check", I would
have to read the name to check if it should return 0 or non-zero if the
fd is selectable.

--

Instead of _PyCheckSelectable_fd(), we can maybe do even better: write a
function to check if a file descriptor is ready to read or write using
poll() (of select() if poll() is not available). Example:

int _Py_FDIsReady(int fd, int writing, double timeout);

Returns:
1: fd is ready to read, or to write if writing is set
0: fd is not ready
-1: error, check errno (or maybe raise a Python error?
internal_select_ex() in socketmodule.c doesn't raise an exception)

("_Py_FDIsReady" name is horrible, but I don't have a better suggestion
yet)

poll() accepts negative timeout, whereas select() doesn't, and so
_PyCheckSelectable_fd() should raise an error if timeout is negative to
be portable.

I propose to use poll() rather than select() because I suppose that it a
little bit faster (maybe only if the fd number is big? e.g. fd=1023) The
difference to wait a single file descriptor is maybe nul.

What should be done in case of EINTR? PyThread_acquire_lock_timed() has
an intr_flag parameter to decide.

I don't think that "int fd" works with SOCKET_T (socket module), which
can be bigger than an int.

Well, _PyCheckSelectable_fd() is much more complex to implement than the
initial suggestion...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Fri Jun 10 00:56:55 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 09 Jun 2011 22:56:55 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1307660215.32.0.27194375567.issue7652@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Fri Jun 10 00:57:43 2011
From: report at bugs.python.org (Michael Mulich)
Date: Thu, 09 Jun 2011 22:57:43 +0000
Subject: [issue12302] pysetup run test
In-Reply-To: <1307660263.81.0.443171517723.issue12302@psf.upfronthosting.co.za>
Message-ID: <1307660263.81.0.443171517723.issue12302@psf.upfronthosting.co.za>


New submission from Michael Mulich <michael.mulich at gmail.com>:

A package's metadata (dist-info) should be available to it while running the test command (pysetup run test)?

The use case:

I've written a test for a function that is supposed to find the default configuration or one provided in a users local area (or {userbase} as sysconfig puts it). As part of the test, I'm ensuring that the forcibly found default config is loaded correctly. The function that finds the configuration uses sysconfig paths (sysconfig.get_paths) which rely on the packaging database (PEP 376 API now in packaging.database).

To find the default config, or resource in packaging terms, I'm using the packaging.database.get_file_path, which requires the distribution metadata (dist-info) be available within the Python path, because it must lookup the RESOURCES file.

I've started work, in my local clone. We lack a unittest for this case. I'll be writing it some time within the next few days.

I'd like to know where this RESOURCES file came from? I don't recall, nor see mention of it in PEP 376. I would also have expected to find something in packaging.command.install_distinfo command related to this file. The install_distinfo command is lacking this logic. I'll add it after the first half of this case working.

----------
assignee: tarek
components: Distutils2
messages: 138032
nosy: alexis, eric.araujo, michael.mulich, tarek
priority: normal
severity: normal
status: open
title: pysetup run test
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12302>
_______________________________________

From report at bugs.python.org  Fri Jun 10 00:57:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jun 2011 22:57:45 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>
Message-ID: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Python 3.3 adds timeout arguments to communicate() and wait() methods of subprocess.Popen, acquire() method of threading.Lock, and maybe more. I like (optional) timeouts, and so it would be nice to have sigtimedwait().

If we expose sigtimedwait(), it's trivial to expose sigwaitinfo(), so should expose both.

----------
components: Extension Modules
messages: 138033
nosy: haypo
priority: normal
severity: normal
status: open
title: expose sigwaitinfo() and sigtimedwait() in the signal module
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Fri Jun 10 01:00:36 2011
From: report at bugs.python.org (Michael Mulich)
Date: Thu, 09 Jun 2011 23:00:36 +0000
Subject: [issue12302] test command is not loading the distribution metadata
In-Reply-To: <1307660263.81.0.443171517723.issue12302@psf.upfronthosting.co.za>
Message-ID: <1307660436.37.0.609901485728.issue12302@psf.upfronthosting.co.za>


Changes by Michael Mulich <michael.mulich at gmail.com>:


----------
title: pysetup run test -> test command is not loading the distribution metadata

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12302>
_______________________________________

From report at bugs.python.org  Fri Jun 10 01:00:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jun 2011 23:00:56 +0000
Subject: [issue12304] expose signalfd(2) in the signal module
In-Reply-To: <1307660456.9.0.497118052372.issue12304@psf.upfronthosting.co.za>
Message-ID: <1307660456.9.0.497118052372.issue12304@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

"Linux offers the signalfd syscall since 2.6.22 (with minor changes afterwards).  This call allows signals to be handled as bytes read out of a file descriptor, rather than as interruptions to the flow of a program.  Quite usefully, this file descriptor can be select()'d on (or poll()'d, epoll()'d, etc) alongside other "normal" file descriptors.

In order to effectively use signalfd(), the signals in question must be blocked, though.  So it makes sense to expose sigprocmask(2) at the same time, in order to allow this blocking to be set up."

This message is copy/pasted from #8407 (msg103182). I created the issue because #8407 contains much more than signalfd().

----------
components: Extension Modules
messages: 138034
nosy: exarkun, haypo
priority: normal
severity: normal
status: open
title: expose signalfd(2) in the signal module
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12304>
_______________________________________

From report at bugs.python.org  Fri Jun 10 01:02:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jun 2011 23:02:35 +0000
Subject: [issue12304] expose signalfd(2) in the signal module
In-Reply-To: <1307660456.9.0.497118052372.issue12304@psf.upfronthosting.co.za>
Message-ID: <1307660555.27.0.909614702421.issue12304@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

signalfd-4.patch: my more recent patch exposing signalfd(). It lacks a structure to decode the bytes read from the signalfd file descriptor. Example in ctypes (msg135438):

class signalfd_siginfo(Structure):
    _fields_ = (
        ('ssi_signo', c_uint32),    # Signal number
        ('ssi_errno', c_int32),     # Error number (unused)
        ('ssi_code', c_int32),      # Signal code
        ('ssi_pid', c_uint32),      # PID of sender
        ('ssi_uid', c_uint32),      # Real UID of sender
        ('ssi_fd', c_int32),        # File descriptor (SIGIO)
        ('ssi_tid', c_uint32),      # Kernel timer ID (POSIX timers)
        ('ssi_band', c_uint32),     # Band event (SIGIO)
        ('ssi_overrun', c_uint32),  # POSIX timer overrun count
        ('ssi_trapno', c_uint32),   # Trap number that caused signal
        ('ssi_status', c_int32),    # Exit status or signal (SIGCHLD)
        ('ssi_int', c_int32),       # Integer sent by sigqueue(2)
        ('ssi_ptr', c_uint64),      # Pointer sent by sigqueue(2)
        ('ssi_utime', c_uint64),    # User CPU time consumed (SIGCHLD)
        ('ssi_stime', c_uint64),    # System CPU time consumed (SIGCHLD)
        ('ssi_addr', c_uint64),     # Address that generated signal
                                    # (for hardware-generated signals)
        ('_padding', c_char * 46),  # Pad size to 128 bytes (allow for
                                    # additional fields in the future)
    )

----------
keywords: +patch
Added file: http://bugs.python.org/file22305/signalfd-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12304>
_______________________________________

From report at bugs.python.org  Fri Jun 10 01:05:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jun 2011 23:05:39 +0000
Subject: [issue8407] expose pthread_sigmask(), pthread_kill(),
	sigpending() and sigwait() in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1307660739.93.0.20798866303.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> This whole thread is becoming quite confusing.

You are complelty right, sorry to pollute this issue. Changes related to this issue:

 - expose pthread_sigmask(), pthread_kill(), sigpending(), sigwait()
 - wakeup fd now contains the file descriptor

I created issue #12303 for sigwaitinfo() and sigtimedwait(), and issue #12304 for signalfd.

----------
title: expose signalfd(2) and pthread_sigmask in the signal module -> expose pthread_sigmask(), pthread_kill(), sigpending() and sigwait() in the signal module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Fri Jun 10 01:07:25 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 09 Jun 2011 23:07:25 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>
Message-ID: <1307660845.91.0.676589871179.issue12303@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Fri Jun 10 01:14:51 2011
From: report at bugs.python.org (Michael Mulich)
Date: Thu, 09 Jun 2011 23:14:51 +0000
Subject: [issue12302] test command is not loading the distribution metadata
In-Reply-To: <1307660263.81.0.443171517723.issue12302@psf.upfronthosting.co.za>
Message-ID: <1307661291.41.0.679268430065.issue12302@psf.upfronthosting.co.za>


Michael Mulich <michael.mulich at gmail.com> added the comment:

The RESOURCES implement in install_distinfo command should probably be a separate case, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12302>
_______________________________________

From report at bugs.python.org  Fri Jun 10 01:27:46 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Jun 2011 23:27:46 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1307662066.05.0.965105086399.issue12009@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is an updated patch with the tests refactored even further.  The patch seems correct to me, and almost all the comment tests fail before the patch and pass after.

Benjamin, this patch fixes a regression relative to 2.7.1 and 3.1.3, so I'm setting it to release blocker so you can decide if it is worth putting in.  netrc is perhaps not a heavily used module, but the fact that we've had several bugs reports that have seen attention and fixes from users recently indicates it *is* used, and is probably worth fixing.  Up to you, though.  Sorry I didn't get this in before the RCs :(

The patch is for 2.7.

----------
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker
stage: patch review -> commit review
Added file: http://bugs.python.org/file22306/netrc-comment-fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Fri Jun 10 01:40:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 09 Jun 2011 23:40:16 +0000
Subject: [issue8407] expose pthread_sigmask(), pthread_kill(),
	sigpending() and sigwait() in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <E1QUopi-0003XR-Dg@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a5c8b6ebe895 by Victor Stinner in branch 'default':
Issue #8407: signal.sigwait() releases the GIL
http://hg.python.org/cpython/rev/a5c8b6ebe895

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Fri Jun 10 01:40:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jun 2011 23:40:58 +0000
Subject: [issue12304] expose signalfd(2) in the signal module
In-Reply-To: <1307660456.9.0.497118052372.issue12304@psf.upfronthosting.co.za>
Message-ID: <1307662858.23.0.693450989417.issue12304@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

#8407 changed the wakeup fd: it now contains the signal number. pthread_sigmask() is now part of Python 3.3 (see also #8407).

signalfd() has advantages over the wakeup fd (msg103326):

 - it is handled in the kernel, the process is not interrupted. For example, system calls cannot fail with EINTR.
 - it gives much more information than the signal number (see signalfd_siginfo structure)
 - it is also possible to have several signalfds, each with a different signal mask. set_wakeup_fd is limited to a single fd per-process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12304>
_______________________________________

From report at bugs.python.org  Fri Jun 10 01:46:21 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 09 Jun 2011 23:46:21 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1307663181.78.0.912903467227.issue12009@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I'd like to see this go in.

+                # seek to the beginning of the comment, then skip the line.
+                pos = len(tt) + 1
+                lexer.instream.seek(-pos, 1)
+                lexer.instream.readline()

Can't you just lexer.instream.readline()?

+        if sys.platform != 'cygwin':
+            mode += 't'

Perhaps this deserves a comment.

+        self.assertEqual({'macro1': ['line1\n', 'line2\n'],
+                          'macro2': ['line3\n', 'line4\n']}, nrc.macros)

It's preferable that the literals are the second argument to assertEqual.

+        self.assertEqual(('bar', None, passwd), nrc.hosts['foo.domain.com'])
+        self.assertEqual(('foo', None, 'pass'), nrc.hosts['bar.domain.com'])
+

Here too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Fri Jun 10 01:54:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jun 2011 23:54:23 +0000
Subject: [issue8407] expose pthread_sigmask(), pthread_kill(),
	sigpending() and sigwait() in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1307663663.89.0.41178639954.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I just noticed something "funny": signal_sigwait doesn't release
> the GIL, which means that it's pretty much useless :-)

sigwait() is not useless: the signal is not necessary send by another thread. The signal can be send by alarm(), from a child process, by an user, by the kernel.

Releasing the GIL is a new feature. Because it is cheap and pause() does also release the GIL, I commited your patch.

> Also, test_sigwait doesn't block the signal before calling sigwait:
> it happens to work because there's only one thread, but it's
> undefined behaviour.

test_sigwait() test pass on all 3.x buildbots (some don't have sigwait(), the test is skipped). Sometimes, test_sigwait() is executed with 2 threads, the main thread and Tkinter event loop thread, and the signal is not blocked in any thread.

On Linux, it works well with more than one thread. I added a test using a thread, we will see if it works on buildbots. The signal is raised by a thread (whereas the signal is not blocked in any thread).

I wrote a can_test_blocked_signals() function in test_signal which has hardcoded tests to check for some known C threads: the faulthandler timeout thread and for the Tkinter event loop thread. can_test_blocked_signals() returns True if pthread_kill() is available.

I don't know how it works if a thread uses pthread_kill() to raise a signal into the main thread (waiting in sigwait()), whereas the signal is not blocked in any thread.

If it is not possible to get the list of all C/Python threads and/or block a signal in all threads, we can use a subprocess without threads (with only the main thread).

Would you like to work on a patch to avoid the undefined behaviour?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Fri Jun 10 02:32:15 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 10 Jun 2011 00:32:15 +0000
Subject: [issue12305] Building PEPs doesn't work on Python 3
In-Reply-To: <1307665935.0.0.179187869363.issue12305@psf.upfronthosting.co.za>
Message-ID: <1307665935.0.0.179187869363.issue12305@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

I found that the .py files are all 2.x.  If I get a chance I will write up a patch a little later.  This is similar to issue #10224.  Incidently, not having done any documentation work before, I didn't realize that docutils isn't in the stdlib.

----------
messages: 138043
nosy: ericsnow
priority: normal
severity: normal
status: open
title: Building PEPs doesn't work on Python 3
type: compile error
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12305>
_______________________________________

From report at bugs.python.org  Fri Jun 10 02:51:04 2011
From: report at bugs.python.org (Torsten Landschoff)
Date: Fri, 10 Jun 2011 00:51:04 +0000
Subject: [issue12306] zlib: Expose zlibVersion to query runtime version of zlib
In-Reply-To: <1307667064.6.0.30417035015.issue12306@psf.upfronthosting.co.za>
Message-ID: <1307667064.6.0.30417035015.issue12306@psf.upfronthosting.co.za>


New submission from Torsten Landschoff <t.landschoff at gmx.net>:

I am currently fighting a curious problem in using zlib from Python: Decompression completes but sometimes the resulting output does not match a sha224 hash of the expected output.

I deployed a zlib 1.2.5 with our PyInstaller output but the problem persists. I would like to check that the program is actually using the right zlib version.

zlib provides the function zlibVersion to access the actual run time version. The attached patch exposes this function from the zlib module. I also added a unit test to check that the function is there and the output matches ZLIB_VERSION (which should match on the build machine).

----------
components: Library (Lib)
files: zlibversion.diff
keywords: patch
messages: 138044
nosy: torsten
priority: normal
severity: normal
status: open
title: zlib: Expose zlibVersion to query runtime version of zlib
type: feature request
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22307/zlibversion.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12306>
_______________________________________

From report at bugs.python.org  Fri Jun 10 03:02:56 2011
From: report at bugs.python.org (Torsten Landschoff)
Date: Fri, 10 Jun 2011 01:02:56 +0000
Subject: [issue12306] zlib: Expose zlibVersion to query runtime version of zlib
In-Reply-To: <1307667064.6.0.30417035015.issue12306@psf.upfronthosting.co.za>
Message-ID: <1307667776.1.0.526543819705.issue12306@psf.upfronthosting.co.za>


Changes by Torsten Landschoff <t.landschoff at gmx.net>:


Added file: http://bugs.python.org/file22308/zlibversion_py3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12306>
_______________________________________

From report at bugs.python.org  Fri Jun 10 04:43:33 2011
From: report at bugs.python.org (John Edmonds)
Date: Fri, 10 Jun 2011 02:43:33 +0000
Subject: [issue12169] Factor out common code for d2 commands register,
	upload and upload_docs
In-Reply-To: <1306255725.22.0.23750798807.issue12169@psf.upfronthosting.co.za>
Message-ID: <1307673813.93.0.287317846726.issue12169@psf.upfronthosting.co.za>


John Edmonds <PocketCookies2 at gmail.com> added the comment:

I'd like to try tackling this issue.  I've made a patch that moves encode_multipart from upload_docs to the distutils2.command module and changed the register and upload commands to use this function.

----------
keywords: +patch
nosy: +John.Edmonds
Added file: http://bugs.python.org/file22309/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12169>
_______________________________________

From report at bugs.python.org  Fri Jun 10 06:19:38 2011
From: report at bugs.python.org (John S. Gruber)
Date: Fri, 10 Jun 2011 04:19:38 +0000
Subject: [issue11933] newer() function in dep_util.py mixes up new vs. old
	files due stat.st_mtime vs stat
In-Reply-To: <1307119157.48.0.757733749663.issue11933@psf.upfronthosting.co.za>
Message-ID: <BANLkTimLwotMxZkOEbq7B+bXD8c7CWDP_Q@mail.gmail.com>


John S. Gruber <johnsgruber at gmail.com> added the comment:

The patch worked--it eliminated the redundant copy caused by this issue.

Thank you very much, ?ric.

On Fri, Jun 3, 2011 at 12:39 PM, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Can you test this patch?

> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11933>
> _______________________________________
>

----------
title: newer() function in dep_util.py mixes up new vs. old files due stat.st_mtime vs stat[ST_MTIME] -> newer() function in dep_util.py mixes up new vs. old files due stat.st_mtime vs stat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11933>
_______________________________________

From report at bugs.python.org  Fri Jun 10 06:44:59 2011
From: report at bugs.python.org (Atsushi Odagiri)
Date: Fri, 10 Jun 2011 04:44:59 +0000
Subject: [issue10191] scripts files are not RECORDed.
In-Reply-To: <1288014947.33.0.874343051999.issue10191@psf.upfronthosting.co.za>
Message-ID: <1307681099.05.0.123083761682.issue10191@psf.upfronthosting.co.za>


Atsushi Odagiri <aodagx at gmail.com> added the comment:

OK, I'll test it too.
I looked sources of packaging. That use packaging.utils.copy_tree.
When I reported that problem, install_scripts used _backport.shutil.copytree. 

Maybe problem is fixed, because it reterned copied file lists.

Is that fixies applied to distutils2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10191>
_______________________________________

From report at bugs.python.org  Fri Jun 10 06:46:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Jun 2011 04:46:57 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307681217.92.0.910042533223.issue12248@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

My preference is to remove the type check.  It hasn't and won't serve a useful purpose so there's no reason to freeze it into the API and have it live on.

That being said, it probably doesn't matter one bit how this report gets resolved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12248>
_______________________________________

From report at bugs.python.org  Fri Jun 10 07:33:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Jun 2011 05:33:19 +0000
Subject: [issue9344] please add posix.getgrouplist()
In-Reply-To: <1279890657.77.0.804697326433.issue9344@psf.upfronthosting.co.za>
Message-ID: <E1QUuLI-0001DM-Cv@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9ebee3211be9 by Ross Lagerwall in branch 'default':
Issue #9344: Add os.getgrouplist().
http://hg.python.org/cpython/rev/9ebee3211be9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9344>
_______________________________________

From report at bugs.python.org  Fri Jun 10 07:50:38 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 10 Jun 2011 05:50:38 +0000
Subject: [issue12307] Inconsistent formatting of section titles in PEP 0
In-Reply-To: <1307685038.6.0.993227913919.issue12307@psf.upfronthosting.co.za>
Message-ID: <1307685038.6.0.993227913919.issue12307@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

The formatting for the title of the "Index by Category" section is different from the formatting for the title of the "Numerical Index" section.  Not sure if there is a reason behind this, but here's a patch:

diff --git a/pep0/output.py b/pep0/output.py
--- a/pep0/output.py
+++ b/pep0/output.py
@@ -169,7 +169,7 @@
         print>>output, unicode(pep)
     print>>output
     print>>output
-    print>>output, u" Numerical Index"
+    print>>output, u"Numerical Index"
     print>>output
     write_column_headers(output)
     prev_pep = 0

----------
messages: 138050
nosy: ericsnow
priority: normal
severity: normal
status: open
title: Inconsistent formatting of section titles in PEP 0
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12307>
_______________________________________

From report at bugs.python.org  Fri Jun 10 07:59:50 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 10 Jun 2011 05:59:50 +0000
Subject: [issue9344] please add posix.getgrouplist()
In-Reply-To: <1279890657.77.0.804697326433.issue9344@psf.upfronthosting.co.za>
Message-ID: <1307685590.84.0.646894094099.issue9344@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Thanks!

----------
resolution:  -> accepted
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9344>
_______________________________________

From report at bugs.python.org  Fri Jun 10 08:05:38 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 10 Jun 2011 06:05:38 +0000
Subject: [issue12308] Add link to PEP 0 for topical index in wiki
In-Reply-To: <1307685938.0.0.639002265247.issue12308@psf.upfronthosting.co.za>
Message-ID: <1307685938.0.0.639002265247.issue12308@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

A couple of months back I started a page on the wiki for a topical index of PEPs from PEP 0 [1].  I got tired of reading through PEPs trying to see if one related to what I was working on.  I found myself wishing there was a topical index of all the PEPs.  The wiki page is the result.

Since it is relatively more dynamic an index than those in PEP 0, I figured it wouldn't work to add it there.  However, I had gotten some support for adding a link to that wiki page to PEP 0, so here's a patch that does so.

I was not sure that the URL should be in the intro, so the patch puts it in its own section right above the Index by Category.

The structure of the wiki page is satisfactory, I hope, and I was able to populate a handful of topics I could think of.  I did not get to very many of the standards-track PEPs.  Still, I think it's a good start and worth linking to in PEP 0.

[1] http://wiki.python.org/moin/Topically_Organized_PEP_List

----------
files: pep0.diff
keywords: patch
messages: 138052
nosy: ericsnow
priority: normal
severity: normal
status: open
title: Add link to PEP 0 for topical index in wiki
versions: Python 3.3
Added file: http://bugs.python.org/file22310/pep0.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12308>
_______________________________________

From report at bugs.python.org  Fri Jun 10 08:28:17 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 10 Jun 2011 06:28:17 +0000
Subject: [issue12273] Change ast.__version__ calculation	to provide consistent
	ordering
In-Reply-To: <1307419934.4.0.45216742345.issue12273@psf.upfronthosting.co.za>
Message-ID: <1307687297.17.0.74781332947.issue12273@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

sys.version_info and sys._mercurial provide all the info needed for someone (like me for mnfy) to know if their code will work against the AST nodes used by the running interpreter. I say drop __version__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12273>
_______________________________________

From report at bugs.python.org  Fri Jun 10 08:41:34 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 10 Jun 2011 06:41:34 +0000
Subject: [issue12304] expose signalfd(2) in the signal module
In-Reply-To: <1307660456.9.0.497118052372.issue12304@psf.upfronthosting.co.za>
Message-ID: <1307688094.61.0.0331956773626.issue12304@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/issue12304>
_______________________________________

From report at bugs.python.org  Fri Jun 10 08:51:42 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 10 Jun 2011 06:51:42 +0000
Subject: [issue12306] zlib: Expose zlibVersion to query runtime version of zlib
In-Reply-To: <1307667064.6.0.30417035015.issue12306@psf.upfronthosting.co.za>
Message-ID: <1307688702.12.0.899674620594.issue12306@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/issue12306>
_______________________________________

From report at bugs.python.org  Fri Jun 10 09:04:35 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 10 Jun 2011 07:04:35 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1307689475.57.0.688589674694.issue1294232@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Fri Jun 10 09:26:17 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 10 Jun 2011 07:26:17 +0000
Subject: [issue12223] Datamodel documentation page: 'operator' where 'operand'
	should be
In-Reply-To: <1306834975.07.0.689179229064.issue12223@psf.upfronthosting.co.za>
Message-ID: <1307690777.29.0.400330361286.issue12223@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

>From a cursory look at reference/datamodel and library/operator, I see no other instances of this error. I didn't read every word, however (just grepped for possible operator/operand mismatches).

Also, AFAICS this error is only in 2.7 - the 3.x docs don't have the relevant paragraphs at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12223>
_______________________________________

From report at bugs.python.org  Fri Jun 10 09:36:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Jun 2011 07:36:52 +0000
Subject: [issue12223] Datamodel documentation page: 'operator' where 'operand'
	should be
In-Reply-To: <1306834975.07.0.689179229064.issue12223@psf.upfronthosting.co.za>
Message-ID: <E1QUwGx-0000uo-Bp@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3bb5400f5bea by Eli Bendersky in branch '2.7':
Issue #12223: Typo fix in datamodel docs
http://hg.python.org/cpython/rev/3bb5400f5bea

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12223>
_______________________________________

From report at bugs.python.org  Fri Jun 10 10:48:14 2011
From: report at bugs.python.org (Ion Scerbatiuc)
Date: Fri, 10 Jun 2011 08:48:14 +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: <1307695694.37.0.148886909506.issue11898@psf.upfronthosting.co.za>


Ion Scerbatiuc <delinhabit at gmail.com> added the comment:

Hello,

I would like to subscribe to the issue. The problem seems to indeed exist in Python 2.7. 

What I'm doing is to proxy HTTP requests (using Django) and the PUT / POST requests are working fine on Python 2.6 but are failing on 2.7 with the error already presented in the first bero's message.

I'm using httplib2 and the code looks like

{{
http = httplib2.Http(timeout=5)
try:
    resp, content = http.request(
        request_url, method,
        body=body, headers=headers)
    except (AttributeError, httplib.ResponseNotReady), e:
        # ...
}}

Body is the result of the Django's request.read() which in fact contain the binary data from the PUT / POST request.

The full stack trace is:
{{
Traceback:
File "/home/cyrus/workspace/macleod/ve/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response
  111.                         response = callback(request, *callback_args, **callback_kwargs)
File "/home/cyrus/workspace/macleod/apps/macleod/macleod/auth.py" in _decorated_view
  33.         return view(request, *args, **kwargs)
File "/home/cyrus/workspace/macleod/ve/lib/python2.7/site-packages/django/views/decorators/csrf.py" in wrapped_view
  39.         resp = view_func(*args, **kwargs)
File "/home/cyrus/workspace/macleod/ve/lib/python2.7/site-packages/django/views/decorators/csrf.py" in wrapped_view
  52.         return view_func(*args, **kwargs)
File "/home/cyrus/workspace/macleod/apps/macleod/macleod/views.py" in dispatch
  55.         original=request.build_absolute_uri())
File "/home/cyrus/workspace/macleod/apps/macleod/macleod/handlers/its.py" in proxy
  51.                 body=body, headers=headers)
File "/home/cyrus/workspace/macleod/ve/lib/python2.7/site-packages/httplib2/__init__.py" in request
  1129.                     (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)
File "/home/cyrus/workspace/macleod/ve/lib/python2.7/site-packages/httplib2/__init__.py" in _request
  901.         (response, content) = self._conn_request(conn, request_uri, method, body, headers)
File "/home/cyrus/workspace/macleod/ve/lib/python2.7/site-packages/httplib2/__init__.py" in _conn_request
  862.                 conn.request(method, request_uri, body, headers)
File "/usr/local/lib/python2.7/httplib.py" in request
  941.         self._send_request(method, url, body, headers)
File "/usr/local/lib/python2.7/httplib.py" in _send_request
  975.         self.endheaders(body)
File "/usr/local/lib/python2.7/httplib.py" in endheaders
  937.         self._send_output(message_body)
File "/usr/local/lib/python2.7/httplib.py" in _send_output
  795.             msg += message_body
}}

----------
nosy: +cyrus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Fri Jun 10 10:56:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jun 2011 08:56:56 +0000
Subject: [issue8407] expose pthread_sigmask(), pthread_kill(),
	sigpending() and sigwait() in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1307696216.48.0.44583843159.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> On Linux, it works well with more than one thread.
> I added a test using a thread, we will see if it works
> on buildbots.

The test hangs on FreeBSD 8.2:

[235/356] test_signal
Timeout (1:00:00)!
Thread 0x0000000800e041c0:
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_signal.py", line 625 in test_sigwait_thread
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/case.py", line 462 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/case.py", line 514 in __call__
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/support.py", line 1166 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/support.py", line 1254 in _run_suite
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/support.py", line 1280 in run_unittest
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_signal.py", line 687 in test_main
  File "./Lib/test/regrtest.py", line 1043 in runtest_inner
  File "./Lib/test/regrtest.py", line 841 in runtest
  File "./Lib/test/regrtest.py", line 668 in main
  File "./Lib/test/regrtest.py", line 1618 in <module>
*** Error code 1

http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/519/steps/test/logs/stdio

(The test has not run yet on FreeBSD 6.4 buildbot)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Fri Jun 10 11:02:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jun 2011 09:02:03 +0000
Subject: [issue12309] os.environ was modified by test_packaging
In-Reply-To: <1307696523.79.0.913575304812.issue12309@psf.upfronthosting.co.za>
Message-ID: <1307696523.79.0.913575304812.issue12309@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

[ 20/356] test_packaging
(...)
Warning -- os.environ was modified by test_packaging

Seen on x86 Tiger buildbot:
http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x/builds/2723/steps/test/logs/stdio

There is also a resource warning:

.../Lib/packaging/pypi/simple.py:86: ResourceWarning: unclosed <socket.socket object, fd=14, family=2, type=1, proto=6>
  return wrapped(self, *args, **kwargs)

----------
components: Tests
messages: 138058
nosy: haypo, tarek
priority: normal
severity: normal
status: open
title: os.environ was modified by test_packaging
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12309>
_______________________________________

From report at bugs.python.org  Fri Jun 10 11:06:30 2011
From: report at bugs.python.org (Ion Scerbatiuc)
Date: Fri, 10 Jun 2011 09:06:30 +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: <1307696790.47.0.967098364144.issue11898@psf.upfronthosting.co.za>


Ion Scerbatiuc <delinhabit at gmail.com> added the comment:

Hello again,

After some digging I found that the "real" problem was because the provided URL was a unicode string and the concatenation was failing. Maybe this is not a big deal, but I think we should least do a proper assertion for the provided URL or some other checks, because the error encountered is at least confusing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Fri Jun 10 11:07:22 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 10 Jun 2011 09:07:22 +0000
Subject: [issue12309] os.environ was modified by test_packaging
In-Reply-To: <1307696523.79.0.913575304812.issue12309@psf.upfronthosting.co.za>
Message-ID: <1307696842.98.0.540218057075.issue12309@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/issue12309>
_______________________________________

From report at bugs.python.org  Fri Jun 10 11:11:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jun 2011 09:11:53 +0000
Subject: [issue12310] Segfault in test_multiprocessing
In-Reply-To: <1307697113.9.0.00979334615642.issue12310@psf.upfronthosting.co.za>
Message-ID: <1307697113.9.0.00979334615642.issue12310@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_multiprocessing segfaults in a loop. The crash occurs in _Condition.release() on waiter.release(), called from Queue._finalize_close(). Possible related changes:

 - a5c8b6ebe895: new sigwait() test using thread (issue #8407)
 - 6d6099f7fe89: add sentinels to multiprocessing (issue #9205)

Example of a crash:

[333/356/1] test_multiprocessing
Fatal Python error: Segmentation fault

Thread 0x01cde800:
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/threading.py", line 237 in wait
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/threading.py", line 690 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/threading.py", line 710 in _bootstrap

Current thread 0xa000d000:
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/threading.py", line 298 in notify
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/queues.py", line 227 in _finalize_close
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/util.py", line 202 in __call__
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/process.py", line 270 in _bootstrap
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/forking.py", line 133 in __init__
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/process.py", line 134 in start
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/pool.py", line 220 in _repopulate_pool
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/pool.py", line 157 in __init__
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/__init__.py", line 231 in Pool
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_multiprocessing.py", line 2186 in test_main
  File "./Lib/test/regrtest.py", line 1043 in runtest_inner
  File "./Lib/test/regrtest.py", line 841 in runtest
  File "./Lib/test/regrtest.py", line 668 in main
  File "./Lib/test/regrtest.py", line 1618 in <module>

There are approximatively 698 crashes in last tests on "x86 Tiger 3.x"!
http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x/builds/2722/steps/test/logs/stdio

Most occured on Queue._finalize_close() -> _Condition.release() -> waiter.release().

----------
messages: 138060
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: Segfault in test_multiprocessing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12310>
_______________________________________

From report at bugs.python.org  Fri Jun 10 11:12:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jun 2011 09:12:23 +0000
Subject: [issue8407] expose pthread_sigmask(), pthread_kill(),
	sigpending() and sigwait() in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1307697143.89.0.721338247863.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The test hangs on FreeBSD 8.2: (...)

See also #12310 which may be related.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Fri Jun 10 11:21:27 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Fri, 10 Jun 2011 09:21:27 +0000
Subject: [issue12311] memory leak with self-referencing dict
In-Reply-To: <1307697687.04.0.359368964586.issue12311@psf.upfronthosting.co.za>
Message-ID: <1307697687.04.0.359368964586.issue12311@psf.upfronthosting.co.za>


New submission from Albert Zeyer <albzey at googlemail.com>:

The attached Python script leaks memory. It is clear that there is a reference circle (`__dict__` references `self`) but `gc.collect()` should find this.

----------
components: Interpreter Core
files: py_dict_refcount_test.py
messages: 138062
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: memory leak with self-referencing dict
type: resource usage
versions: Python 3.2
Added file: http://bugs.python.org/file22311/py_dict_refcount_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12311>
_______________________________________

From report at bugs.python.org  Fri Jun 10 11:26:34 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Fri, 10 Jun 2011 09:26:34 +0000
Subject: [issue12311] memory leak with self-referencing dict
In-Reply-To: <1307697687.04.0.359368964586.issue12311@psf.upfronthosting.co.za>
Message-ID: <1307697994.43.0.861275392737.issue12311@psf.upfronthosting.co.za>


Albert Zeyer <albzey at googlemail.com> added the comment:

Whoops, looks like a duplicate of #1469629.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12311>
_______________________________________

From report at bugs.python.org  Fri Jun 10 11:26:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jun 2011 09:26:49 +0000
Subject: [issue12310] Segfault in test_multiprocessing
In-Reply-To: <1307697113.9.0.00979334615642.issue12310@psf.upfronthosting.co.za>
Message-ID: <1307698009.0.0.959905125146.issue12310@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> a5c8b6ebe895: new sigwait() test using thread (issue #8407)
> 6d6099f7fe89: add sentinels to multiprocessing (issue #9205)


The first segfaults occured in build #2719 (cedceeb45030):
http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x/builds/2719

In the timeline, 6d6099f7fe89 < cedceeb45030 < a5c8b6ebe895, so the change is more likely coming from 6d6099f7fe89.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12310>
_______________________________________

From report at bugs.python.org  Fri Jun 10 11:27:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jun 2011 09:27:50 +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: <1307698070.31.0.640999271386.issue9205@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_multiprocessing crashs ~700 times on Mac OS X Tiger, regression likely introduced by this issue (6d6099f7fe89): I created issue #12310 for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Fri Jun 10 11:30:11 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 10 Jun 2011 09:30:11 +0000
Subject: [issue8407] expose pthread_sigmask(), pthread_kill(),
	sigpending() and sigwait() in the signal module
In-Reply-To: <1307663663.89.0.41178639954.issue8407@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=Rk4+b=xtjuUjySEYt5vwf+DQFAQ@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

>> I just noticed something "funny": signal_sigwait doesn't release
>> the GIL, which means that it's pretty much useless :-)
>
> sigwait() is not useless: the signal is not necessary send by another thread. The signal can be send by alarm(), from a child process, by an user, by the kernel.
>

If it doesn't release the GIL, it is useless.
The common usage pattern for sigwait() is to create a dedicated thread
for signals management. If this thread calls sigwait without releasing
the GIL, the whole process is suspended, which is definitely not what
you want.

>> Also, test_sigwait doesn't block the signal before calling sigwait:
>> it happens to work because there's only one thread, but it's
>> undefined behaviour.
>
> test_sigwait() test pass on all 3.x buildbots (some don't have sigwait(), the test is skipped). Sometimes, test_sigwait() is executed with 2 threads, the main thread and Tkinter event loop thread, and the signal is not blocked in any thread.
>

It's mere luck:

    def test_sigwait(self):
        old_handler = signal.signal(signal.SIGALRM, self.handler)
        self.addCleanup(signal.signal, signal.SIGALRM, old_handler)

        signal.alarm(1)
        self.assertEqual(signal.sigwait([signal.SIGALRM]), signal.SIGALRM)

Comment out the first two lines that change the signal handler, and
the test will be killed by SIGALRM's default handler ("Alarm clock").
I tested on Linux, and if a the signal isn't blocked before calling sigwait:
- if a custom signal handler is installed, then it is not called
- if the default signal handler is in place, then it's called (and
with SIGALRM the process gets killed)
This is a typical example of what POSIX calls "undefined behavior".
If pthread_sigmask is called before sigwait, then it works as expected.

If we really wanted to test this properly, the way to go would be to
fork() a child process (that way we're sure there's only one thread),
have it block and sigwait() SIGUSR1 without touching the handler, send
it SIGUSR1, and check its return code.
Patch attached.

----------
Added file: http://bugs.python.org/file22312/test_sigwait.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________
-------------- next part --------------
--- cpython-302424b84b07/Lib/test/test_signal.py	2011-06-01 04:39:38.000000000 +0200
+++ cpython/Lib/test/test_signal.py	2011-06-10 10:47:33.521906867 +0200
@@ -601,11 +601,24 @@
     @unittest.skipUnless(hasattr(signal, 'sigwait'),
                          'need signal.sigwait()')
     def test_sigwait(self):
-        old_handler = signal.signal(signal.SIGALRM, self.handler)
-        self.addCleanup(signal.signal, signal.SIGALRM, old_handler)
-
-        signal.alarm(1)
-        self.assertEqual(signal.sigwait([signal.SIGALRM]), signal.SIGALRM)
+        # sigwait must be called with the signal blocked: since the current
+        # process might have several threads running, we fork() a child process
+        # to have a single thread.
+        signum = signal.SIGUSR1
+        pid = os.fork()
+        if pid == 0:
+            # child: block and wait the signal
+            signal.pthread_sigmask(signal.SIG_BLOCK, [signum])
+            res = signal.sigwait([signum])
+            if res == signum:
+                os._exit(0)
+            os._exit(1)
+        else:
+            # parent: let the child some time to wait, send him the signal, and
+            # check it correcty received it
+            time.sleep(0.5)
+            os.kill(pid, signum)
+            self.assertEqual(os.waitpid(pid, 0), (pid, 0))
 
     @unittest.skipUnless(hasattr(signal, 'pthread_sigmask'),
                          'need signal.pthread_sigmask()')

From report at bugs.python.org  Fri Jun 10 11:40:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Jun 2011 09:40:29 +0000
Subject: [issue12310] Segfault in test_multiprocessing
In-Reply-To: <1307697113.9.0.00979334615642.issue12310@psf.upfronthosting.co.za>
Message-ID: <1307698829.86.0.515977300976.issue12310@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Victor, how can there be hundreds of crashes? Isn't the process supposed to terminate when a crash occurs?

There are several crashes in test_signal, so it's not only test_multiprocessing:


Thread 0xa000d000:
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", line 172 in test_main
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 462 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 514 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 1166 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1254 in _run_suite
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1280 in run_unittest
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", line 687 in test_main
  File "./Lib/test/regrtest.py", line 1043 in runtest_inner
  File "./Lib/test/regrtest.py", line 841 in runtest
  File "./Lib/test/regrtest.py", line 668 in main
  File "./Lib/test/regrtest.py", line 1618 in <module>
Fatal Python error: Segmentation fault


Thread 0xa000d000:
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", line 248 in test_wakeup_fd_early
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 462 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 514 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 1166 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1254 in _run_suite
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1280 in run_unittest
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", line 687 in test_main
  File "./Lib/test/regrtest.py", line 1043 in runtest_inner
  File "./Lib/test/regrtest.py", line 841 in runtest
  File "./Lib/test/regrtest.py", line 668 in main
  File "./Lib/test/regrtest.py", line 1618 in <module>
Fatal Python error: Segmentation fault



Thread 0xa000d000:
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", line 372 in readpipe_interrupted
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", line 394 in test_siginterrupt_on
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 462 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 514 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 1166 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1254 in _run_suite
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1280 in run_unittest
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", line 687 in test_main
  File "./Lib/test/regrtest.py", line 1043 in runtest_inner
  File "./Lib/test/regrtest.py", line 841 in runtest
  File "./Lib/test/regrtest.py", line 668 in main
  File "./Lib/test/regrtest.py", line 1618 in <module>
Fatal Python error: Segmentation fault



Thread 0xa000d000:
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", line 495 in test_itimer_prof
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 462 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 514 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 1166 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1254 in _run_suite
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1280 in run_unittest
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", line 687 in test_main
  File "./Lib/test/regrtest.py", line 1043 in runtest_inner
  File "./Lib/test/regrtest.py", line 841 in runtest
  File "./Lib/test/regrtest.py", line 668 in main
  File "./Lib/test/regrtest.py", line 1618 in <module>
Fatal Python error: Segmentation fault



Thread 0xa000d000:
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", line 472 in test_itimer_virtual
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 462 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 514 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 1166 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1254 in _run_suite
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1280 in run_unittest
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", line 687 in test_main
  File "./Lib/test/regrtest.py", line 1043 in runtest_inner
  File "./Lib/test/regrtest.py", line 841 in runtest
  File "./Lib/test/regrtest.py", line 668 in main
  File "./Lib/test/regrtest.py", line 1618 in <module>
Fatal Python error: Segmentation fault

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12310>
_______________________________________

From report at bugs.python.org  Fri Jun 10 11:40:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Jun 2011 09:40:52 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1307698852.73.0.503119589216.issue12009@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

lexer.instream.readline(): no, we can't just call that without the seek, because reading the token that started with # may have caused the line to be consumed already.  I've expanded the comment to explain this.

cygwin: I'd add a comment if I knew what that was for.  This was copied from the existing tests.

order of assertEqual args: this reversed style was the existing style in the test file, but since we are doing a full refactor anyway I've consistently reversed them in the updated patch.

Should I apply these to the current branches (including 3.1) or is it easier for you to do it in your release clones?  If you do it, note that the test patch doesn't apply cleanly to 3.x, but that's only because of a couple of PEP8ifications (a space was removed from between the name and the '(' in a couple function calls in 3.x), which should be easy enough to adjust by hand in order to apply the patch.

----------
Added file: http://bugs.python.org/file22313/netrc-comment-fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Fri Jun 10 11:42:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jun 2011 09:42:50 +0000
Subject: [issue12310] Segfault in test_multiprocessing
In-Reply-To: <1307697113.9.0.00979334615642.issue12310@psf.upfronthosting.co.za>
Message-ID: <1307698970.3.0.227587005869.issue12310@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Victor, how can there be hundreds of crashes?
> Isn't the process supposed to terminate when a crash occurs?

Yes, a process does terminate on SIGSEGV, but multiprocessing creates subprocesses: I suppose that crashes occur in child processes.

For test_signal, I have to investigate this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12310>
_______________________________________

From report at bugs.python.org  Fri Jun 10 11:59:37 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 10 Jun 2011 09:59:37 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1307699977.6.0.974850820019.issue12291@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Attached is an improved patch:

1. It's against the 3.2 branch, rather than default.
2. It has an added multiple load test in test_marshal.py.
3. There's more error checking for an EOF condition.
4. I've removed tab chars and used /* C89 comments */.

Of course it's not as fast as the 2.x version, since that had a limitation on only being able to load from file objects, and a fast path for PyFile using stdio calls directly. Hard to compete with that!

Suggestions for improvements gratefully received :-)

----------
keywords: +needs review
Added file: http://bugs.python.org/file22314/marshal-patch2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Fri Jun 10 12:00:00 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 10 Jun 2011 10:00:00 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1307700000.98.0.0979691422063.issue12291@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Fri Jun 10 12:30:56 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Jun 2011 10:30:56 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1307701856.85.0.852355418277.issue11416@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This should not be applied until after the patch for #12009 is applied, at which point the test will need to be adjusted.  #12009 completely refactors the netrc test suite.

I wonder if the 'hosts' attribute should be deprecated, but let's leave that discussion for another day :)

Since this requires an API change, it is a feature and can only go into 3.3.  I've adjusted 'versions' accordingly.

----------
type: behavior -> feature request
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Fri Jun 10 12:49:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Jun 2011 10:49:51 +0000
Subject: [issue8407] expose pthread_sigmask(), pthread_kill(),
	sigpending() and sigwait() in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <E1QUzHi-0000Sz-C1@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a17710e27ea2 by Victor Stinner in branch 'default':
Issue #8407: Make signal.sigwait() tests more reliable
http://hg.python.org/cpython/rev/a17710e27ea2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Fri Jun 10 12:59:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jun 2011 10:59:18 +0000
Subject: [issue8407] expose pthread_sigmask(), pthread_kill(),
	sigpending() and sigwait() in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1307703558.6.0.865064878055.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

neologix> Patch attached.

I wrote a different patch based on your patch. The main change is that I chose to keep signal.alarm(1) instead of sending the signal from the parent process to the child process, because I don't think that time.sleep(0.5) is a reliable synchronization code to wait until the child process is waiting in sigwait().

test_sigwait_thread() uses time.sleep(1) to wait until the main thread is waiting in sigwait(), but it is not mandatory because the signal is already blocked in the thread. I wrote test_sigwait_thread() to ensure that sigwait() releases the GIL, not to check that if a thread raises a signal while sigwait() is waiting, sigwait() does correctly receive it.

We may use time.sleep() in test_sigwait() if the signal is blocked in the parent process before the fork() (and unblocked in the parent process after the fork, but before sending the signal to the child process), but I think that signal.alarm() is more reliable and simple.

--

test_sigwait(_thread) was the last known bug of this issue, so let's close it. Reopen it if you see other bugs in pthread_sigmask(), pthread_kill(), sigpending() and sigwait() functions, or maybe better: open new issues because this issue has a too long history! See issue #12303 for sigwaitinfo() and sigtimedwait(), and issue #12304 for signalfd.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Fri Jun 10 13:02:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jun 2011 11:02:10 +0000
Subject: [issue12310] Segfault in test_multiprocessing
In-Reply-To: <1307698829.86.0.515977300976.issue12310@psf.upfronthosting.co.za>
Message-ID: <1307703718.3135.0.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le vendredi 10 juin 2011 ? 09:40 +0000, Antoine Pitrou a ?crit :
> There are several crashes in test_signal

Commit a17710e27ea2 should fix some (all?) test_signal crashes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12310>
_______________________________________

From report at bugs.python.org  Fri Jun 10 13:47:16 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 10 Jun 2011 11:47:16 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1307706436.72.0.858919606166.issue12287@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> I don't understand if socket file descriptors are different than
> (classic) file descriptors.

On Windows, sockets are completely independent from file descriptors.

A socket id can be large (typically over 1000), fortunately a fd_set is not indexed by descriptors; FD_SET just appends the socket descriptor to the array; there is a limit of 64 sockets, but no limit on the value of a descriptor.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Fri Jun 10 13:53:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Jun 2011 11:53:47 +0000
Subject: [issue8407] expose pthread_sigmask(), pthread_kill(),
	sigpending() and sigwait() in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <E1QV0HZ-0006bZ-Lj@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 37a87b709403 by Victor Stinner in branch 'default':
Issue #8407: write error message on sigwait test failure
http://hg.python.org/cpython/rev/37a87b709403

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Fri Jun 10 14:02:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Jun 2011 12:02:40 +0000
Subject: [issue8407] expose pthread_sigmask(), pthread_kill(),
	sigpending() and sigwait() in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <E1QV0QB-0007V9-DQ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 60b1ab4d0cd4 by Victor Stinner in branch 'default':
Issue #8407: skip sigwait() tests if pthread_sigmask() is missing
http://hg.python.org/cpython/rev/60b1ab4d0cd4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Fri Jun 10 15:37:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jun 2011 13:37:51 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1307713071.79.0.529735593281.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Version 2 of my patch (mbcs2.patch):
 - patch also the encoder: fix ignore/replace depending on the Windows version, support any error handler: encode character per character if encoding in strict mode fails
 - Add PyUnicode_DecodeCodePageStateful() and PyUnicode_EncodeCodePage() functions
 - Expose these functions as codecs.code_page_decode() and codecs.code_page_encode()

The encoder raises a RuntimeError("recursive call") (ugly message!) if the result of the error handler is a Unicode string that cannot be encoded to the code page.

More TODO:

 - write tests using codecs.code_page_decode() and codecs.code_page_encode()
 - Fix FIXME (e.g. support surrogates in the encoder)

----------
Added file: http://bugs.python.org/file22315/mbcs2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Fri Jun 10 15:44:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jun 2011 13:44:49 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1307713489.98.0.651161906104.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Example on Windows Vista with ANSI=cp932:

>>> import codecs
>>> codecs.code_page_encode(1252, '\xe9')
(b'\xe9', 1)
>>> codecs.mbcs_encode('\xe9')
...
UnicodeEncodeError: 'mbcs' codec can't encode characters in position 0--1: invalid character
>>> codecs.code_page_encode(932, '\xe9')
...
UnicodeEncodeError: 'cp932' codec can't encode characters in position 0--1: invalid character
>>> codecs.code_page_encode(932, '\xe9', 'replace')
(b'e', 1)
>>> codecs.code_page_encode(932, '\xe9', 'ignore')
(b'', 8)
>>> codecs.code_page_encode(932, '\xe9', 'backslashreplace')
(b'\\xe9', 8)

You can use a code page different than the ANSI code page.

The encoding name is generated from the code page number: "cp%u" % code_page, or "mbcs" if code_page == CP_ACP.

(Oops, I forgot a printf() in mbcs2.patch)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Fri Jun 10 15:48:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jun 2011 13:48:20 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1307713700.45.0.513641696145.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Decode examples, ANSI=cp932:

>>> codecs.code_page_decode(1252, b'\x80')
('\u20ac', 1)
>>> codecs.code_page_decode(932, b'\x82')
...
UnicodeDecodeError: 'mbcs' codec can't decode bytes in position 0--1: No mapping for the Unicode character exists in the target code page.
>>> codecs.code_page_decode(932, b'\x82', 'replace')
('?', 1)
>>> codecs.code_page_decode(932, b'\x82', 'ignore')
('', 0)

Oh, the encoding name is wrong in the decoding errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Fri Jun 10 16:35:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Jun 2011 14:35:36 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <E1QV2oA-0003ud-Je@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 33b7428e65b4 by Victor Stinner in branch '3.1':
Issue #10801: Fix test_unicode_filenames() of test_zipfile
http://hg.python.org/cpython/rev/33b7428e65b4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10801>
_______________________________________

From report at bugs.python.org  Fri Jun 10 17:23:58 2011
From: report at bugs.python.org (tanushree)
Date: Fri, 10 Jun 2011 15:23:58 +0000
Subject: [issue12312] is ok
In-Reply-To: <BANLkTim4bSurSVFgiKP9dKweiPEBAG+DoA@mail.gmail.com>
Message-ID: <BANLkTim4bSurSVFgiKP9dKweiPEBAG+DoA@mail.gmail.com>


New submission from tanushree <tanushree.ghosal at gmail.com>:

thank u very much for registering me .

----------
messages: 138082
nosy: tanushree.ghosal at gmail.com
priority: normal
severity: normal
status: open
title: is ok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12312>
_______________________________________

From report at bugs.python.org  Fri Jun 10 17:24:18 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 10 Jun 2011 15:24:18 +0000
Subject: [issue12312] is ok
In-Reply-To: <BANLkTim4bSurSVFgiKP9dKweiPEBAG+DoA@mail.gmail.com>
Message-ID: <1307719458.36.0.53536213714.issue12312@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12312>
_______________________________________

From report at bugs.python.org  Fri Jun 10 17:37:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 15:37:59 +0000
Subject: [issue7969] shutil.copytree error handling non-standard and partially
	broken
In-Reply-To: <1266617058.24.0.24785922897.issue7969@psf.upfronthosting.co.za>
Message-ID: <1307720279.68.0.311996630306.issue7969@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  Have you had a chance to investigate Terry?s question?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7969>
_______________________________________

From report at bugs.python.org  Fri Jun 10 17:41:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 15:41:01 +0000
Subject: [issue11975] Fix referencing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1307720461.61.0.0593974548152.issue11975@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

When I said ?I don?t like the idea of built-in functions being displayed as ?builtins.int??, I was thinking about the output of ?.. function:: int? in combination with the module directive.  I don?t know if using currentmodule instead of module would be better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Fri Jun 10 17:43:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 15:43:46 +0000
Subject: [issue10191] scripts files are not RECORDed.
In-Reply-To: <1288014947.33.0.874343051999.issue10191@psf.upfronthosting.co.za>
Message-ID: <1307720626.29.0.142850667644.issue10191@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> OK, I'll test it too.
Thanks.  In case you?re not sure how to test my patch, see http://docs.python.org/devguide/faq#how-do-i-apply-a-patch and http://docs.python.org/devguide/runtests

> I looked sources of packaging. That use packaging.utils.copy_tree.
> When I reported that problem, install_scripts used backport.shutil.copytree.
Ah, I see a comment in the code that copy_tree should be replaced by shutil.copytree, so we need to get the test anyway to make sure changing the code later will not cause a regression.

> Maybe problem is fixed, because it reterned copied file lists.
Indeed.

> Is that fixies applied to distutils2?
distutils2 will be recreated as a backport of packaging.  IOW, the packaging module in the 3.3 stdlib is the distutils2 project.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10191>
_______________________________________

From report at bugs.python.org  Fri Jun 10 17:45:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 15:45:16 +0000
Subject: [issue12298] Sphinx glitch in library/functions
In-Reply-To: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za>
Message-ID: <1307720716.28.0.901594699939.issue12298@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

memoryview and frozenset do have a small entry in library/functions, and the links at the top of the file are meant to jump to entries in the same file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12298>
_______________________________________

From report at bugs.python.org  Fri Jun 10 17:49:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 15:49:47 +0000
Subject: [issue12169] Factor out common code for d2 commands register,
	upload and upload_docs
In-Reply-To: <1306255725.22.0.23750798807.issue12169@psf.upfronthosting.co.za>
Message-ID: <1307720987.4.0.254401146697.issue12169@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your contribution.  Unfortunately, I used ?distutils2? as a familiar name for what is now known as the packaging module, in the 3.3 standard library.  This document should help you find the right codebase to work from: http://wiki.python.org/moin/Distutils/Contributing

Regarding the new location of the moved code, I think the util module would be a better choice than command.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12169>
_______________________________________

From report at bugs.python.org  Fri Jun 10 17:52:39 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 10 Jun 2011 15:52:39 +0000
Subject: [issue11975] Fix referencing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1307721159.18.0.581882043046.issue11975@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Why is any module directive needed anyway?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Fri Jun 10 17:53:35 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 10 Jun 2011 15:53:35 +0000
Subject: [issue12298] Sphinx glitch in library/functions
In-Reply-To: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za>
Message-ID: <1307721215.66.0.372443991219.issue12298@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, then a different way of linking to them must be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12298>
_______________________________________

From report at bugs.python.org  Fri Jun 10 17:56:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 15:56:54 +0000
Subject: [issue12298] Sphinx glitch in library/functions
In-Reply-To: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za>
Message-ID: <1307721414.14.0.450437029173.issue12298@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Certainly.  I tried using `.memoryview` without success.  How would you do it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12298>
_______________________________________

From report at bugs.python.org  Fri Jun 10 17:57:41 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 10 Jun 2011 15:57:41 +0000
Subject: [issue12298] Sphinx glitch in library/functions
In-Reply-To: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za>
Message-ID: <1307721461.8.0.867468967691.issue12298@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You can put an anchor and use :ref:.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12298>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:01:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 16:01:26 +0000
Subject: [issue12302] packaging test command needs access to .dist-info
In-Reply-To: <1307660263.81.0.443171517723.issue12302@psf.upfronthosting.co.za>
Message-ID: <1307721686.64.0.540536180913.issue12302@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> while running the test command (pysetup run test)?
Yes, that?s the correct invocation.

> The use case: [...]
I agree with the need.  I?ve added a dep on the bug requesting the addition of a build_distinfo command; once it is done, this bug will be solved, since test runs build and places the build lib in sys.path (which also enables running tests on code converted by 2to3 at build time).

> The function that finds the configuration uses sysconfig paths
> (sysconfig.get_paths) which rely on the packaging database (PEP 376
> API now in packaging.database).
sysconfig does rely on packaging.

> To find the default config, or resource in packaging terms, I'm using
> the packaging.database.get_file_path, which requires the distribution
> metadata (dist-info) be available within the Python path
This however is correct.

> I'd like to know where this RESOURCES file came from? I don't recall,
> nor see mention of it in PEP 376.
This is the implementation of the discussion originally started in https://bitbucket.org/tarek/distutils2/src/6c3d67ed3adb/docs/design/wiki.rst  I think it was originally intended to be a new PEP, but during distutils2 sprints it was directly coded.  Resources replace data_files.

> I would also have expected to find something in
> packaging.command.install_distinfo command related to this file.
It?s subtle; grep for RESOURCES and you?ll find it.  The list of files is built by install_data and written by install_distinfo.  If you want to learn more about this code, go to a distutils2 repo and look at the log.

----------
assignee: tarek -> eric.araujo
dependencies: +Add build_distinfo command to packaging
title: test command is not loading the distribution metadata -> packaging test command needs access to .dist-info

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12302>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:02:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 16:02:35 +0000
Subject: [issue2057] difflib: add patch capability
In-Reply-To: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>
Message-ID: <1307721755.8.0.568574673972.issue2057@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A productive thing to do would be to ask feedback on python-ideas for this new feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2057>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:04:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 16:04:09 +0000
Subject: [issue12302] packaging test command needs access to .dist-info
In-Reply-To: <1307660263.81.0.443171517723.issue12302@psf.upfronthosting.co.za>
Message-ID: <1307721849.33.0.51133597005.issue12302@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Typo: sysconfig does *not* rely on packaging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12302>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:05:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 16:05:03 +0000
Subject: [issue12298] Sphinx glitch in library/functions
In-Reply-To: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za>
Message-ID: <1307721903.63.0.636856747017.issue12298@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sounds like the easiest solution that could work, thanks.  I?m on it.

----------
assignee: docs at python -> eric.araujo
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12298>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:06:18 2011
From: report at bugs.python.org (Tres Seaver)
Date: Fri, 10 Jun 2011 16:06:18 +0000
Subject: [issue8407] expose pthread_sigmask(), pthread_kill(),
	sigpending() and sigwait() in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1307721978.71.0.223539655424.issue8407@psf.upfronthosting.co.za>


Changes by Tres Seaver <tseaver at agendaless.com>:


----------
nosy:  -tseaver

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:08:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 16:08:02 +0000
Subject: [issue12313] make install misses packaging module
In-Reply-To: <1307722082.95.0.13819638115.issue12313@psf.upfronthosting.co.za>
Message-ID: <1307722082.95.0.13819638115.issue12313@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Here?s a patch adding Lib/packaging subdirectories to Makefile.pre.in.  Because of our extensive tests for pypi-related code, the list is huge.  Maybe it should use a call to find(1) instead of using a fragile manually-maintained list, so I?m asking here.

----------
components: Installation
files: add-packaging-makefile.pre.in.diff
keywords: patch
messages: 138096
nosy: eric.araujo
priority: normal
severity: normal
stage: patch review
status: open
title: make install misses packaging module
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file22316/add-packaging-makefile.pre.in.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12313>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:10:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 16:10:39 +0000
Subject: [issue12222] All pysetup commands should respect exit codes
In-Reply-To: <1306833373.02.0.231767797102.issue12222@psf.upfronthosting.co.za>
Message-ID: <1307722239.24.0.356964552589.issue12222@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Here?s a patch adding ?return 1? after all errors, unifying the use of logging and cleaning up a few things (like moving KeyboardInterrupt handling from the _run function up to the main function).

----------
keywords: +patch
Added file: http://bugs.python.org/file22317/p7g-run-cleanup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12222>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:11:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 16:11:47 +0000
Subject: [issue12222] All pysetup commands should respect exit codes
In-Reply-To: <1306833373.02.0.231767797102.issue12222@psf.upfronthosting.co.za>
Message-ID: <1307722307.13.0.47408590361.issue12222@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

BTW, some functions do not explicitly return 0, but this is okay: they will return None, which is a boolean false value, which is understood as 0 by sys.exit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12222>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:14:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 16:14:20 +0000
Subject: [issue12309] os.environ was modified by test_packaging
In-Reply-To: <1307696523.79.0.913575304812.issue12309@psf.upfronthosting.co.za>
Message-ID: <1307722460.31.0.204568624148.issue12309@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If you don?t add the distutils2 component or our name to the nosy field, we can?t react quickly :)

I don?t know our networking code enough to track down the socket-related resource warnings; I?ll look into the os.environ issue.

----------
assignee:  -> eric.araujo
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12309>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:15:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Jun 2011 16:15:26 +0000
Subject: [issue10897] UNIX mmap unnecessarily dup() file descriptor
In-Reply-To: <1294845379.76.0.427887707002.issue10897@psf.upfronthosting.co.za>
Message-ID: <1307722526.89.0.276264925751.issue10897@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, I agree on the principle, but it is a change in behaviour and would probably break some user code...
Perhaps by adding some new argument to the mmap constructor? (dup_fd = True)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10897>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:19:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 16:19:09 +0000
Subject: [issue12314] regrtest checks (os.environ, sys.path,
	etc.) are hard to use
In-Reply-To: <1307722749.85.0.48203387339.issue12314@psf.upfronthosting.co.za>
Message-ID: <1307722749.85.0.48203387339.issue12314@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

When regrtest tells me that os.environ was modified by test_packaging, it?s very hard to find which test is responsible.  The -vv output is hard to read: it prints four dictionaries, which I have to visually delineate, copy, paste, pretty-print and diff to find what?s changed.  Then I edit the source code of regrtest so that it fails earlier, or I add a debug print in the packaging.util code that touches os.environ.

I?d like regrtest to tell me what exactly was changed, and where.  For the first request, I think each checked object could use a type-specific method, for example _compare_dict would see if any value was changed and if keys are different, and print only that info.

----------
components: Tests
messages: 138101
nosy: eric.araujo
priority: normal
severity: normal
status: open
title: regrtest checks (os.environ, sys.path, etc.) are hard to use
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12314>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:19:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 16:19:18 +0000
Subject: [issue12309] os.environ was modified by test_packaging
In-Reply-To: <1307696523.79.0.913575304812.issue12309@psf.upfronthosting.co.za>
Message-ID: <1307722758.62.0.839381727765.issue12309@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +regrtest checks (os.environ, sys.path, etc.) are hard to use

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12309>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:19:47 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 10 Jun 2011 16:19:47 +0000
Subject: [issue12248] __dir__ semantics changed in Python 2.7.2
In-Reply-To: <1307057554.2.0.779854000267.issue12248@psf.upfronthosting.co.za>
Message-ID: <1307722787.77.0.373405063882.issue12248@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I look at it this way: If I was browsing the 2.7 code and saw that type check, would I remove it in the bugfix release? No.

I'm going to mark this resolved. Thanks everyone.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12248>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:21:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Jun 2011 16:21:32 +0000
Subject: [issue9344] please add posix.getgrouplist()
In-Reply-To: <1279890657.77.0.804697326433.issue9344@psf.upfronthosting.co.za>
Message-ID: <1307722892.93.0.31011185745.issue9344@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Nit: when a patch gets committed and the issue closed, the preferred resolution is "fixed" ;)
(see http://docs.python.org/devguide/triaging.html#resolution)

----------
resolution: accepted -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9344>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:22:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 16:22:15 +0000
Subject: [issue12305] Building PEPs doesn't work on Python 3
In-Reply-To: <1307665935.0.0.179187869363.issue12305@psf.upfronthosting.co.za>
Message-ID: <1307722935.59.0.99985022032.issue12305@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I started to work on this some months ago, so I can review your patch.

Before you start, it?s probably worth asking on python-dev or pydotorg whether the machines that build and host the PEPs have Python 3 installed.  I can ask on your behalf if you don?t feel confident enough to post on python-dev; feel free to reply through the core-mentorship list.

----------
components: +None
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12305>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:24:12 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 10 Jun 2011 16:24:12 +0000
Subject: [issue9344] please add posix.getgrouplist()
In-Reply-To: <1279890657.77.0.804697326433.issue9344@psf.upfronthosting.co.za>
Message-ID: <1307723052.9.0.0154699929109.issue9344@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> Nit: when a patch gets committed and the issue closed, the preferred
> resolution is "fixed" ;)
> (see http://docs.python.org/devguide/triaging.html#resolution)

Sure, I will try remember that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9344>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:35:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Jun 2011 16:35:06 +0000
Subject: [issue12218] Removing wsgiref.egg-info
In-Reply-To: <1306774248.3.0.608189461621.issue12218@psf.upfronthosting.co.za>
Message-ID: <E1QV4fo-0005ea-JR@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c12401a83a13 by ?ric Araujo in branch 'default':
Remove *.egg-info from Makefile.pre.in (follow-up to d615eb7bce33, #12218)
http://hg.python.org/cpython/rev/c12401a83a13

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12218>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:35:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Jun 2011 16:35:06 +0000
Subject: [issue12246] Warn when trying to install third-party module from an
	uninstalled checkout
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <E1QV4fo-0005ea-Ju@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ff58eec3336b by ?ric Araujo in branch 'default':
Don?t try to install something when running from uninstalled source (#12246).
http://hg.python.org/cpython/rev/ff58eec3336b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12246>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:46:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 16:46:10 +0000
Subject: [issue12246] Warn when trying to install third-party module from an
	uninstalled checkout
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307724370.05.0.388337408102.issue12246@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed.  Welcome to Misc/ACKS !

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12246>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:52:26 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Jun 2011 16:52:26 +0000
Subject: [issue12314] regrtest checks (os.environ, sys.path,
	etc.) are hard to use
In-Reply-To: <1307722749.85.0.48203387339.issue12314@psf.upfronthosting.co.za>
Message-ID: <1307724746.95.0.0547787487882.issue12314@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Improvements are welcome, the whole thing was a QnD hack that has been evolving over time...maybe there's some way to reuse unittest's assertEqual machinery?

I also wonder if the whole environment-changed thing should be moved into unittest so it could wrap around individual test methods.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12314>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:52:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Jun 2011 16:52:53 +0000
Subject: [issue12314] regrtest checks (os.environ, sys.path,
	etc.) are hard to use
In-Reply-To: <1307722749.85.0.48203387339.issue12314@psf.upfronthosting.co.za>
Message-ID: <1307724773.92.0.640382417255.issue12314@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> needs patch
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12314>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:56:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 16:56:23 +0000
Subject: [issue12314] regrtest checks (os.environ, sys.path,
	etc.) are hard to use
In-Reply-To: <1307722749.85.0.48203387339.issue12314@psf.upfronthosting.co.za>
Message-ID: <1307724983.43.0.0599783418108.issue12314@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> maybe there's some way to reuse unittest's assertEqual machinery?
Hum, I think the diff functionality is cleanly separated in a (private) method, so we could get diff for free.

> I also wonder if the whole environment-changed thing should be moved
> into unittest so it could wrap around individual test methods.
Yeah, I was thinking about a WatchfulTestRunner that would perform the same checks.  It annoys me to have two diverging sets of features to run tests: either checks with regrtest, or failfast, discovery and granularity with unittest.

----------
nosy: +ezio.melotti, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12314>
_______________________________________

From report at bugs.python.org  Fri Jun 10 18:57:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Jun 2011 16:57:33 +0000
Subject: [issue12306] zlib: Expose zlibVersion to query runtime version of zlib
In-Reply-To: <1307667064.6.0.30417035015.issue12306@psf.upfronthosting.co.za>
Message-ID: <1307725053.66.0.343078875623.issue12306@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Good idea, and thanks for posting a patch! This is a new feature, so 3.3-only. Also, you'll need to update the docs (Doc/library/zlib.rst, presumably) to add the new module method/attribute (with a suitable "versionadded" tag).

Nitpicking:
- "zlibVersion" isn't PEP8-compliant
- semantically it should probably be a module-level attribute, rather than a method; after all it's kind of a constant; perhaps ZLIB_RUNTIME_VERSION?

Also, I see that ZLIB_VERSION itself isn't documented, it would be nice to have a separate patch to fix that.

----------
nosy: +pitrou
stage:  -> patch review
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12306>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:02:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 17:02:46 +0000
Subject: [issue12168] SysLogHandler incorrectly appends \000 to messages
In-Reply-To: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>
Message-ID: <1307725366.8.0.864461692605.issue12168@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Should this new attribute be documented?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12168>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:03:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 17:03:41 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1307725421.09.0.644569055006.issue11610@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/issue11610>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:04:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 17:04:31 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <1307725471.54.0.526898135977.issue9788@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Here?s a patch.

----------
keywords: +needs review, patch
resolution: accepted -> 
stage: needs patch -> patch review
versions: +Python 3.3 -Python 3.1
Added file: http://bugs.python.org/file22318/doc-atexit-order-undefined.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:05:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 17:05:54 +0000
Subject: =?utf-8?b?W2lzc3VlODg4N10g4oCccHlkb2Mgc3Ry4oCdIHdvcmtzIGJ1dCBub3Qg4oCc?=
	=?utf-8?q?pydoc_str=2Etranslate=E2=80=9D?=
In-Reply-To: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>
Message-ID: <1307725554.0.0.781216321824.issue8887@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I added tests to cover non-existing attributes and updated the code to follow your clever suggestion.

----------
Added file: http://bugs.python.org/file22319/fix-pydoc-str.translate-3.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8887>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:06:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 17:06:36 +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: <1307725596.39.0.807656460016.issue8982@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed 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  Fri Jun 10 19:07:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 17:07:02 +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: <1307725622.91.0.217674064346.issue8982@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch refreshed.  If I get no negative feedback, I?ll commit it next week.

----------
Added file: http://bugs.python.org/file22320/fix-argparse-class-directive.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8982>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:11:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Jun 2011 17:11:12 +0000
Subject: [issue12197] non-blocking SSL write fails if a partial write was
	issued
In-Reply-To: <1306519609.32.0.152577977388.issue12197@psf.upfronthosting.co.za>
Message-ID: <1307725872.77.0.389106860281.issue12197@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't see any discrepancy here (with Python 3.3). Under both Linux and Windows, the client thread prints:

ERR [Errno 3] _ssl.c:1126: The operation did not complete (write)
done

The only difference is that the server thread receives 128KB under Linux, and 48KB under Windows.

I think the main variation comes not from OpenSSL, but from the OS's thread scheduling algorithms. If you do a large write, you have to be prepared to get an error, because the buffers may be too small.

I agree it might seem strange that OpenSSL returns an error rather than the number of sent bytes, and this behaviour could actually be changed at the OpenSSL level (see http://www.openssl.org/docs/ssl/SSL_write.html) by allowing people to use the SSL_MODE_ENABLE_PARTIAL_WRITE option. However, doing so by default could break existing code which assumes that writes either fail or succeed completely.

issue8240 talks about a slightly related request.

----------
title: non-blocking SSL write in Windows sends large data but raises exception -> non-blocking SSL write fails if a partial write was issued
type: behavior -> feature request
versions: +Python 3.3 -Python 2.6, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12197>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:14:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 17:14:57 +0000
Subject: [issue12306] zlib: Expose zlibVersion to query runtime version of zlib
In-Reply-To: <1307667064.6.0.30417035015.issue12306@psf.upfronthosting.co.za>
Message-ID: <1307726097.97.0.473147385715.issue12306@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/issue12306>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:15:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 17:15:36 +0000
Subject: [issue5243] Missing dependency in distutils build
In-Reply-To: <1234519029.27.0.18013582736.issue5243@psf.upfronthosting.co.za>
Message-ID: <1307726136.57.0.316952540816.issue5243@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>> Now something I don't understand is how reportlab distribution is doing
>> to copy the compiled extensions when "install" is called.
> I think clib stuff is installed in the right python directory and the
> ext install step then just finds them.
Yep, the install* commands just copy all files from the build dir to the install dir.

The patch is straightforward and the test looks good.  However, I worry about backward compatibility.  For projects without C libs, this won?t change anything; for projects already having a workaround, what will happen?  While this is clearly a bug, I?m not sure fixing the existing behavior is okay in distutils.

For packaging (distutils2), I will commit this shortly.

----------
resolution: accepted -> 
stage:  -> patch review
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5243>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:17:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Jun 2011 17:17:58 +0000
Subject: [issue12053] Add prefetch() for Buffered IO (experiment)
In-Reply-To: <1306610234.1.0.791958193778.issue12053@psf.upfronthosting.co.za>
Message-ID: <1307726271.3653.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I started a draft in python. I am attaching the _pyio version along
> with tests. I will continue work on the C implementation and
> eventually documentation if this is well received. It seems
> straightforward, I am interested to see what you guys think.

Thank you. I think performance measurements are prematurate until we
have an optimized C implementation anyway.

I think ultimately we also want a default implementation of read(),
peek() and read1() which uses prefetch(), so that BufferedReader
implementations only have to implement prefetch().
(care must be taken to avoid infinite loops)

That said, I think the python-dev mailing-list needs to be convinced of
the usefulness of prefetch() (if it was only me, there wouldn't be any
problem :-)). Perhaps you want to run another discussion there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12053>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:19:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Jun 2011 17:19:05 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1307726345.86.0.297701920123.issue8240@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

See issue12197 for a related request.

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:20:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Jun 2011 17:20:34 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1307726434.12.0.64506195963.issue12167@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is someone investigating this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:31:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Jun 2011 17:31:43 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <E1QV5Yc-0001sj-Cv@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset cb3a77b0f8dd by Benjamin Peterson in branch '2.7':
fix regression in netrc comment handling (closes #12009)
http://hg.python.org/cpython/rev/cb3a77b0f8dd

New changeset 6993910be426 by Benjamin Peterson in branch '2.7':
merge 2.7.2 release branch with fix for #12009
http://hg.python.org/cpython/rev/6993910be426

New changeset 8625ce7da152 by Benjamin Peterson in branch '3.1':
fix regression in netrc comment handling (closes #12009)
http://hg.python.org/cpython/rev/8625ce7da152

New changeset 6b93cbb69e49 by Benjamin Peterson in branch '3.2':
merge 3.1 (#12009)
http://hg.python.org/cpython/rev/6b93cbb69e49

New changeset 734831b62549 by Benjamin Peterson in branch 'default':
merge 3.2 (#12009)
http://hg.python.org/cpython/rev/734831b62549

----------
nosy: +python-dev
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:44:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 17:44:16 +0000
Subject: [issue11553] Docs for: import, packages, site.py, .pth files
In-Reply-To: <1300189190.68.0.0305569633639.issue11553@psf.upfronthosting.co.za>
Message-ID: <1307727856.07.0.562811283086.issue11553@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the detailed review.  I?d like to work on a number of them.  I think I?ll open focused bug reports and make this one depend on them; this will let interested people see the new bugs and possibly give feedback.

> The Language Reference is way too complicated for the mainstream case.
Well, it is not a user guide, but a language reference.  Its scope is different from the library reference.

> Exactly what variants of arguments are possible, and what are their effects?
Does http://docs.python.org/dev/library/functions#__import__ help? Does http://docs.python.org/dev/library/importlib ?

> What are the interactions with package features, such as whether or not
> modules have been explicitly imported into package __init_.py?
Ah, that?s a common issue.  I?ll look into the turorial and docs for import and make a patch.

> Details of package structure have evidently changed over Python versions.
I don?t think so.

> Current docs are unclear on points such as:
> -- is __init__.py needed on subpackage directories?
Yes, it always has.  I think there was some discussion about removing them in py3k, but this was rejected.

> -- the __all__ variable: Does it act generally to limit visibility of a
> module or package's attributes, or does pertain only to the
> 'from...import *' statement?
Both.  http://docs.python.org/dev/genindex-_ leads me to http://docs.python.org/dev/reference/simple_stmts#index-44 and http://docs.python.org/dev/c-api/import#index-0  The doc is there; I however agree that the tutorial or libref could have the same info.

> Language Reference
> Grammar issue: the grammar shown for the import statement shows: [snip]
I have no inkling on that one; I?ll create another bug and ask the import experts.

> Really 'module' is not quite right here either since it's used to mean module-or-package.
A package is a type of module.
                                                                                                
> site.py:
I think I?ll focus first on my work about improving the site.rst documentation, then open another bug to synchronize the docstrings.

> Seriously misleading discussion of .pth files.  [snip]
Agreed.  I believe this section dates back to the pre-package days, where projects like PIL had a module, a .pth file and a directory with modules on sys.path.

> The docstring (or other docs) should make clear that .pth files
> are ONLY processed within site-package directories (ie: only by site.py)
I?ll add a section about the ?site directories? in the docs.  They?re defined in site.py or by users calling site.addsitedir.

> In addsitepackages(), the library directory for Windows (the else clause)
> is shown as lower-case 'lib' instead of 'Lib'.
I don?t see any else clause in the 2.7 or 3.3 code.  Otherwise you?re right.


> Tutorial [snip]
All valid points.


> Standard Library Reference
> site
> This page may simply be importing the docstring from site.py?
> In any case it repeats the ommissions and errors noted above for site.py.
We don?t use docstring extraction in CPython.  Code and docs are updated alongside, or like here, get oudated in parallel.

> sys
> Could helpfully point to a discussion of the typical items to
> be found in sys.path under normal circumstances
Hm, this would be very platform-specific.  What use cases would that help?

> pkgutil
I?ll have to read again the code and PEPs to comment on that one.

> 'Installing Python Modules' document
> "Windows has no concept of a user?s home directory, " and so on.
The author probably meant that there was no $HOME environment variable, ~ shortcut and all that.  Even though Windows assigns a directory for each user, it?s not quite a home dir, but the parent of a settings dir, a documents dir, etc.  (Just like on Mac OS X, there is a UNIX-style home dir, but the tools present another directory for users? documents, IIRC.)

> For Windows suggests 'prefix' (default: C:\Python) as an installation directory.
> This is indeed one of the possible 'site-package' directories, but surely it is
> deprecated in favor of C:\Python\Lib\site-packages, which this section does not mention.
Don?t confuse the prefix and the install dir.  The directory for Python modules is computed as prefix + Lib/site-packages.

> Does not mention user-specific site-package directories.
That?s #10745.  I documented it in http://docs.python.org/dev/packaging/commandref#install-dist but it?s not done for distutils docs yet.

> 'Modifying Python's Search Path' [snip]
> (a) .pth files are only processed in site-package directories.
Yes.  I?ll probably link to the site docs after we write out a clean section on .pth files.  There are other parts of the distutils docs that duplicate information found in docs.python.org/dev/using, for example; I?ll remove them from the packaging (distutils2) docs.

> (b) Clarifying an additional point of confusion [...]
We don?t over-explain every implication in the docs; see http://docs.python.org/dev/documenting/style.html#affirmative-tone

> PEP 302 New Import Hooks
This would be a valid point to raise on python-dev.

That was my initial feeback; I think I?ve covered all of your points.  Some time next week I?ll open the focused bugs and start on patches.

----------
assignee: docs at python -> eric.araujo
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11553>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:46:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 17:46:18 +0000
Subject: [issue11553] Docs for: import, packages, site.py, .pth files
In-Reply-To: <1300189190.68.0.0305569633639.issue11553@psf.upfronthosting.co.za>
Message-ID: <1307727978.2.0.429726309791.issue11553@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +Better document user site-packages in site module doc, setup.py install --user option undocumented

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11553>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:49:33 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 10 Jun 2011 17:49:33 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <1307728173.13.0.738119488047.issue9788@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I don't think the order should be defined.

I disagree.
The C standard explicitely states that the functions are called in LIFO order (which is the natural order in this case).

The current implementation guarantees LIFO order, I think it should be documented.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:49:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 17:49:40 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1307728180.13.0.119467200054.issue12167@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m afraid I don?t understand enough to fix this.  I looked at test_simple_built in test_command_bdist_dumb and found no C code involved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:50:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Jun 2011 17:50:32 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1307728180.13.0.119467200054.issue12167@psf.upfronthosting.co.za>
Message-ID: <1307728225.3653.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I?m afraid I don?t understand enough to fix this.  I looked at
> test_simple_built in test_command_bdist_dumb and found no C code
> involved.

It means that either packaging or test_packaging keeps references to
more and more objects.
You don't need to know C, but you have to investigate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:52:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Jun 2011 17:52:31 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1307728351.45.0.882138993521.issue12167@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ah, it?s just refcounting issues?  I can probably use the gc module to find them, and add del statements where appropriate to release objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:53:16 2011
From: report at bugs.python.org (Michael Mulich)
Date: Fri, 10 Jun 2011 17:53:16 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1307461733.49.0.987510653631.issue12279@psf.upfronthosting.co.za>
Message-ID: <1307728396.22.0.789206267229.issue12279@psf.upfronthosting.co.za>


Changes by Michael Mulich <michael.mulich at gmail.com>:


----------
nosy: +michael.mulich

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Fri Jun 10 19:54:27 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Jun 2011 17:54:27 +0000
Subject: [issue12168] SysLogHandler incorrectly appends \000 to messages
In-Reply-To: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>
Message-ID: <E1QV5uc-0003fN-21@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3cf5d61fd6d7 by Vinay Sajip in branch '3.2':
Documented change for Issue #12168.
http://hg.python.org/cpython/rev/3cf5d61fd6d7

New changeset 6658b9b9f5f3 by Vinay Sajip in branch 'default':
Merged documentation change for Issue #12168.
http://hg.python.org/cpython/rev/6658b9b9f5f3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12168>
_______________________________________

From report at bugs.python.org  Fri Jun 10 20:00:16 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 10 Jun 2011 18:00:16 +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: <1307728816.26.0.439890320978.issue11898@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Ion, as you perhaps noticed, posting a message 'subscribes' you (puts you on the nosy list). One can also add oneself as nosy with the little button under it without saying anything.

This should be reopened because we do not change error classes in bugfix releases (ie, future 2.7.x releases) because that can break code -- unless the error class is contrary to the doc and we decide the doc is right. Even as a new feature, a change is dubious and carefully to be considered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Fri Jun 10 21:22:56 2011
From: report at bugs.python.org (harobed)
Date: Fri, 10 Jun 2011 19:22:56 +0000
Subject: [issue12315] Improve http.client.HTTPResponse.read documentation
In-Reply-To: <1307733776.17.0.904388798994.issue12315@psf.upfronthosting.co.za>
Message-ID: <1307733776.17.0.904388798994.issue12315@psf.upfronthosting.co.za>


New submission from harobed <stephane at harobed.org>:

This is a patch to improve http.client.HTTPResponse.read documentation.

What do you think about ?

----------
assignee: docs at python
components: Documentation
files: improve_http.client_documentation.patch
keywords: patch
messages: 138129
nosy: docs at python, harobed
priority: normal
severity: normal
status: open
title: Improve http.client.HTTPResponse.read documentation
versions: Python 3.3
Added file: http://bugs.python.org/file22321/improve_http.client_documentation.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12315>
_______________________________________

From report at bugs.python.org  Fri Jun 10 21:25:57 2011
From: report at bugs.python.org (Bryan Schmersal)
Date: Fri, 10 Jun 2011 19:25:57 +0000
Subject: [issue1590864] Function-level import in os triggering an threaded
	import deadlock
Message-ID: <1307733957.38.0.158746835966.issue1590864@psf.upfronthosting.co.za>


Bryan Schmersal <bryan.schmersal at gmail.com> added the comment:

I have a module that I was using on 2.5 that uses subprocess.Popen to monitor the output from some external programs in several different threads.  Of course, subprocess.Popen uses os.fork.  When I upgraded to 2.7 which includes this fix, this module ran into a deadlock since the fork is being executed from within an import.  One could argue that my approach is poor style but one of the goals of this module is simplicity for the users....they simply need to import it to get the functionality of the module.

Was this a desired side-effect?

----------
nosy: +Bryan.Schmersal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1590864>
_______________________________________

From report at bugs.python.org  Fri Jun 10 22:05:12 2011
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 10 Jun 2011 20:05:12 +0000
Subject: [issue12246] Warn when trying to install third-party module from an
	uninstalled checkout
In-Reply-To: <1307724370.05.0.388337408102.issue12246@psf.upfronthosting.co.za>
Message-ID: <1307736274.28315.0.camel@debian>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

On Fri, 2011-06-10 at 16:46 +0000, ?ric Araujo wrote:
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> Fixed.  Welcome to Misc/ACKS !

loveliness :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12246>
_______________________________________

From report at bugs.python.org  Fri Jun 10 23:10:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jun 2011 21:10:43 +0000
Subject: [issue12310] Segfault in test_multiprocessing
In-Reply-To: <1307697113.9.0.00979334615642.issue12310@psf.upfronthosting.co.za>
Message-ID: <1307740243.82.0.783461625508.issue12310@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It looks like the sentinel doesn't handle fatal death of the child process:

test test_multiprocessing crashed -- Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 1043, in runtest_inner
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_multiprocessing.py", line 2189, in test_main
    ManagerMixin.manager.start()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/managers.py", line 531, in start
    self._address = reader.recv()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/connection.py", line 273, in recv
    buf = self._recv_bytes(sentinels=sentinels)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/connection.py", line 430, in _recv_bytes
    buf = self._recv(4, sentinels)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/connection.py", line 413, in _recv
    raise EOFError
EOFError

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12310>
_______________________________________

From report at bugs.python.org  Fri Jun 10 23:24:46 2011
From: report at bugs.python.org (Darren Dale)
Date: Fri, 10 Jun 2011 21:24:46 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1307741086.78.0.526220927236.issue11610@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

I posted the following at python-dev (http://mail.python.org/pipermail/python-dev/2011-June/111837.html):

I would like to try to address some shortfalls with the way python deals with
abstract base classes containing descriptors. I originally was just concerned
with improving support for defining abstract properties with the decorator
syntax and converting between abstract and concrete properties, but recently
realized that the problem extends to descriptors in general.

ABCs
----

First, a bit of background may be in order. An abstract base class is defined
by specifying its metaclass as ABCMeta (or a subclass thereof)::

   class MyABC(metaclass=ABCMeta):
       @abstractmethod
       def foo(self):
           pass

When trying to instantiate MyABC or any of its subclasses, ABCMeta inspects the
current class namespace for items tagged with __isabstractmethod__=True::

   class ABCMeta(type):
   #[...]
       def __new__(mcls, name, bases, namespace):
           cls = super().__new__(mcls, name, bases, namespace)
           # Compute set of abstract method names
           abstracts = {name
                        for name, value in namespace.items()
                        if getattr(value, "__isabstractmethod__", False)}

ABCMeta then checks if any of the base classes define any items tagged with
__isabstractmethod__ and whether they remain abstract in the current
class namespace::

           for base in bases:
               for name in getattr(base, "__abstractmethods__", set()):
                   value = getattr(cls, name, None)
                   if getattr(value, "__isabstractmethod__", False):
                       abstracts.add(name)
           cls.__abstractmethods__ = frozenset(abstracts)

In Objects/typeobject.c, __abstractmethods__ is actually a descriptor, and
setting it gives the type a chance to set an internal flag specifying if it
has any abstract methods defined. When object_new is called in typeobject.c,
the flag is checked and an error is raised if any abstract methods were
identified.

Issues with ABCs and descriptors
--------------------------------

In order for this scheme to work, ABCMeta needs to identify all of the abstract
methods, but there are some limitations when we consider descriptors. For
example, Python's property is a composite object, whose behavior is defined by
the getter, setter, and deleter methods with which it is composed. Since there
is already an @abstractmethod decorator, I would have suspected that defining
abstract properties would be intuitive::

   class MyABC(metaclass=ABCMeta):
       @abstractmethod
       def _get_foo(self):
           pass
       @abstractmethod
       def _set_foo(self, val):
           pass
       foo = property(_get_foo, _set_foo)

       @property
       @abstractmethod
       def bar(self):
           pass
       @bar.setter
       @abstractmethod
       def bar(self, val):
           pass

Ideally, one would want the flexibility of defining a concrete getter and an
abstract setter, for example. However, ABCMeta does not inspect the descriptors
of a class to see if they contain any abstract methods. It only inspects the
descriptor itself for a True __isabstractmethod__ attribute. This places the
burdon on every descriptor implementation to provide its own support for ABC
compatibility. For example, support for abstract properties was attempted by
adding abstractproperty to the abc module. abstractproperty subclasses the
property builtin (as opposed to the relationship between every other abstract
and concrete class in the python language). Here is the definition of
abstractproperty, in its entirety (modulo docstrings)::

   class abstractproperty(property):
       __isabstractmethod__ = True

A number of problems manifest with this approach, and I think they all can be
traced to the fact that the abstractedness of a descriptor is currently not
dependent upon the abstractedness of the methods with which it is
composed. The documentation for abstractproperty doesn't suggest using
@abstractmethod::

       class C(metaclass=ABCMeta):
           def getx(self): ...
           def setx(self, value): ...
           x = abstractproperty(getx, setx)

which leads to Issue #1: What is abstract about C.x? How does a subclass of C
know whether it needs to override the getter or setter?

Issue #2: The decorator syntax cannot be used to convert an abstract property
into a concrete one. (This relates to Issue #1: how would a descriptor even know
when such a conversion would be appropriate?) Running the following code::

   from abc import ABCMeta, abstractmethod, abstractproperty

   class AbstractFoo(metaclass=ABCMeta):
       @abstractproperty
       def bar(self):
           return 1
       @bar.setter
       def bar(self, val):
           pass

   class ConcreteFoo(AbstractFoo):
       @AbstractFoo.bar.getter
       def bar(self):
           return 1
       @bar.setter
       def bar(self, val):
           pass
   foo = ConcreteFoo()

yields::

   TypeError: Can't instantiate abstract class ConcreteFoo with abstract
   methods bar

Issue #3: The following class *is* instantiable, even though
AbstractFoo declared that a setter for bar is required::

   class ConcreteFoo(AbstractFoo):
       @property
       def bar(self):
           pass

Previous attempt to improve abc.abstractproperty
------------------------------------------------

It seems to me that the strategy used by abc.abstractproperty is fundamentally
ill-advised. I explored the possibility of extending abstractproperty,
redefining its getter, setter, and deleter methods such that they would work in
conjunction with the @abstractmethod decorator and yield an instance of the
builtin property once all abstract methods were replaced with concrete ones
(http://bugs.python.org/issue11610). Issues #1 and #2 were addressed, but there
were still problems with that approach. It did not address Issue #3, and it
also introduced a new issue, #4::

   class AbstractFoo(metaclass=ABCMeta):
       @abstractproperty
       # bar would be an abstractproperty, even though the getter is concrete
       def bar(self):
           return 1
       @bar.setter
       # bar.setter inspected the getter and the new setter, did not identify
       # any abstract methods, and thus returned an instance of the built-in
       # property
       def bar(self, val):
           pass
       @bar.deleter
       # bar is a concrete property, its deleter decorator does not know it
       # is supposed to check for abstract methods, so it will return an
       # instance of the built-in property:
       @abstractmethod
       def bar(self):
           pass

By the time the deleter was specified, bar was a concrete property, which does
not know it should return an instance of abstractproperty (in part because the
inheritance diagram for property/abstractproperty is inverted). Thus,
AbstractFoo was instantiable, even though it shouldn't be.

Finally, issue #5: the current approach taken by ABCMeta and abstractproperty
places the burdon on descriptors to identify themselves to ABCMeta as
abstract. Considering the issues encountered with abstractproperty, this may be
an onerous requirement.

There has been a fair amount of discussion at http://bugs.python.org/issue11610
, which can be summarized as a) concerns about maintaining backward
compatibility, and b) objections to requiring @abstractmethod to specify that a
method being passed to abstractproperty is abstract.

Extending ABCMeta: A Promising Way Forward
------------------------------------------

I think the key is to focus on Issue #3. ABCMeta needs to be improved to
recognize descriptor objects, both in the current namespace as well as the base
classes, and to identify any abstract methods associated with the
descriptors. I suggest the following approach in ABCMeta::

   def __new__(mcls, name, bases, namespace):
       cls = super().__new__(mcls, name, bases, namespace)
       # Compute set of abstract method names

       def isdescriptor(val):
           return hasattr(val, '__get__') or hasattr(val, '__set__') \
                   or hasattr(val, '__delete__')
       def getabstracts(ns):
           return [name
                   for name, value in ns.items()
                   if getattr(value, "__isabstractmethod__", False)]

       abstracts = getabstracts(namespace)
       for item, val in namespace.items():
           # further inspect descriptors for abstract methods:
           if isdescriptor(val):
               ## unfortunately, can't import inspect:
               #from inspect import getmembers
               #d = dict(getmembers(val))
               ## so instead, use the following:
               d = dict((k, getattr(val, k, None)) for k in dir(val))
               for name in getabstracts(d):
                   # add the abstract descriptor methods to the list:
                   abstracts.append('%s.%s'%(item, name))
       for base in bases:
           for name in getattr(base, "__abstractmethods__", set()):
               if '.' in name:
                   # base class identified a descriptor abstract method:
                   k, v = name.split('.')
                   desc = getattr(cls, k, None)
                   val = getattr(desc, v, None)
               else:
                   val = getattr(cls, name, None)
               if val is None or getattr(val, "__isabstractmethod__", False):
                   abstracts.append(name)
       cls.__abstractmethods__ = frozenset(abstracts)

I rolled everything into __new__ just to keep it as simple as possible for the
sake of discussion. Python already provides the rest of the framework needed
for descriptors to work properly with ABCs. This implementation actually works;
I've tested it with an existing python-3.2 install::

   from abc import ABCMeta, abstractmethod

   class AbstractFoo(metaclass=ABCMeta):
       @property
       @abstractmethod
       def bar(self):
           return 1
       @bar.setter
       @abstractmethod
       def bar(self, val):
           pass

   >>> abstractfoo = AbstractFoo()
   Traceback (most recent call last):
     File "temp.py", line 17, in <module>
       abstractfoo = AbstractFoo()
   TypeError: Can't instantiate abstract class AbstractFoo with abstract
   methods bar.fget, bar.fset

as expected. Note the more informative error message indicating what about the
bar property is abstract. Also::

   class ConcreteFoo(AbstractFoo):
       @AbstractFoo.bar.getter
       def bar(self):
           return 1

   >>> foo = ConcreteFoo()
   Traceback (most recent call last):
     File "temp.py", line 24, in <module>
       foo = ConcreteFoo()
   TypeError: Can't instantiate abstract class ConcreteFoo with abstract
   methods bar.fset

So issue #1 is addressed, since we are explicitly specifying which descriptor
methods are abstract. Issue #2 has been addressed, since the following class is
instantiable::

   class ConcreteFoo(AbstractFoo):
       @AbstractFoo.bar.getter
       def bar(self):
           return 1
       @bar.setter
       def bar(self, val):
           pass

Issue #3 is also addressed. In the following example, even though I redefine
the bar property as a readonly property, ABCMeta recognizes that a setter is
needed::

   class ConcreteFoo(AbstractFoo):
       @property
       def bar(self):
           return 1

   >>> foo = ConcreteFoo()
   Traceback (most recent call last):
     File "temp.py", line 24, in <module>
       foo = ConcreteFoo()
   TypeError: Can't instantiate abstract class ConcreteFoo with abstract
   methods bar.fset

Issue #4 (introduced in a previous attempt to solve the problem
using abstractproperty) is also addressed::

   class AbstractFoo(metaclass=ABCMeta):
       @property
       def bar(self):
           return 1
       @bar.setter
       def bar(self, val):
           pass
       @bar.deleter
       @abstractmethod
       def bar(self):
           pass

   >>> abstractfoo = AbstractFoo()
   Traceback (most recent call last):
     File "temp.py", line 15, in <module>
       abstractfoo = AbstractFoo()
   TypeError: Can't instantiate abstract class AbstractFoo with abstract
   methods bar.fdel

Finally, this approach addresses Issue #5 by holding ABCMeta responsible for
identifying the abstractedness of descriptor methods, rather than placing that
burdon on the desciptor objects to identify themselves as abstract. If ABCMeta
were extended as above to identify abstract methods associated with
descriptors, third parties would simply decorate methods used to compose the
descriptors with @abstractmethod.

This change to ABCMeta would not effect the behavior of abstractproperty, so
backward compatibility would be maintained in that respect. But I think
abstractproperty should be deprecated, or at the very least removed from the
documentation. The documentation for @abstractmethod in >=python-3.3 should be
extended to provide examples with properties/descriptors. The syntax would be
backward compatible with older python versions, but with <python-3.3 ABCMeta
would simply not recognize descriptors' abstract methods. This leads to one
source of potential forward compatibility::

   class AbstractFoo(metaclass=ABCMeta):
       @property
       @abstractmethod
       def bar(self):
           return 1

   class ConcreteFoo(AbstractFoo):
       pass

Both above classes would be instantiable with <python-3.3, but not with
>=python3.3. In my opinion, this is a feature: python-3.3 has identified a bug
in ConcreteFoo. The developer would not have tagged that method as abstract
unless they had intended for consumers of AbstractFoo to provide a concrete
implementation.

----------
title: Improving property to accept abstract methods -> Improved support for abstract base classes with descriptors

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Fri Jun 10 23:29:24 2011
From: report at bugs.python.org (Darren Dale)
Date: Fri, 10 Jun 2011 21:29:24 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1307741364.19.0.00338350887091.issue11610@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

Here is an improved patch, which includes feedback from python-dev. "make test" runs without failures, however test_abc.py prints deprecation warnings for abstractproperty. I'm not familiar with the protocol here, do we continue to include unit tests for deprecated features until they are removed?

----------
Added file: http://bugs.python.org/file22322/abc_descriptors.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Fri Jun 10 23:38:25 2011
From: report at bugs.python.org (Darren Dale)
Date: Fri, 10 Jun 2011 21:38:25 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1307741905.72.0.00312219749814.issue11610@psf.upfronthosting.co.za>


Changes by Darren Dale <dsdale24 at gmail.com>:


Removed file: http://bugs.python.org/file22322/abc_descriptors.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Fri Jun 10 23:38:53 2011
From: report at bugs.python.org (Darren Dale)
Date: Fri, 10 Jun 2011 21:38:53 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1307741933.59.0.100671847021.issue11610@psf.upfronthosting.co.za>


Changes by Darren Dale <dsdale24 at gmail.com>:


Added file: http://bugs.python.org/file22323/abc_descriptors.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Fri Jun 10 23:45:28 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 10 Jun 2011 21:45:28 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307706436.72.0.858919606166.issue12287@psf.upfronthosting.co.za>
Message-ID: <BANLkTikUSiAMqgJa941ZW7o97mrkqTEHLg@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

Two patches attached:
- a patch checking that the ossaudiodev object isn't closed
- a patch adding _PyIsSelectable_fd()

----------
Added file: http://bugs.python.org/file22324/is_selectable.diff
Added file: http://bugs.python.org/file22325/oss_check_closed.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________
-------------- next part --------------
diff -r e572a97a1bd1 Include/fileobject.h
--- a/Include/fileobject.h	Fri Jun 10 19:05:16 2011 +0100
+++ b/Include/fileobject.h	Fri Jun 10 23:35:14 2011 +0200
@@ -44,6 +44,15 @@
 #endif
 #endif /* Py_LIMITED_API */
 
+#ifdef HAVE_SELECT
+/* A routine to check if a file descriptor can be select()-ed. */
+#ifdef Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE
+ #define _PyIsSelectable_fd(FD) (1)
+#else
+ #define _PyIsSelectable_fd(FD) (((FD) >= 0) && ((FD) < FD_SETSIZE))
+#endif
+#endif /* HAVE_SELECT */
+
 #ifdef __cplusplus
 }
 #endif
diff -r e572a97a1bd1 Modules/_ssl.c
--- a/Modules/_ssl.c	Fri Jun 10 19:05:16 2011 +0100
+++ b/Modules/_ssl.c	Fri Jun 10 23:35:14 2011 +0200
@@ -1022,10 +1022,8 @@
 #endif
 
     /* Guard against socket too large for select*/
-#ifndef Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE
-    if (s->sock_fd >= FD_SETSIZE)
+    if (!_PyIsSelectable_fd(s->sock_fd))
         return SOCKET_TOO_LARGE_FOR_SELECT;
-#endif
 
     /* Construct the arguments to select */
     tv.tv_sec = (int)s->sock_timeout;
diff -r e572a97a1bd1 Modules/ossaudiodev.c
--- a/Modules/ossaudiodev.c	Fri Jun 10 19:05:16 2011 +0100
+++ b/Modules/ossaudiodev.c	Fri Jun 10 23:35:14 2011 +0200
@@ -425,6 +425,11 @@
     if (!PyArg_ParseTuple(args, "y#:write", &cp, &size))
         return NULL;
 
+    if (!_PyIsSelectable_fd(self->fd)) {
+        PyErr_SetString(PyExc_ValueError,
+                        "file descriptor out of range for select");
+        return NULL;
+    }
     /* use select to wait for audio device to be available */
     FD_ZERO(&write_set_fds);
     FD_SET(self->fd, &write_set_fds);
diff -r e572a97a1bd1 Modules/selectmodule.c
--- a/Modules/selectmodule.c	Fri Jun 10 19:05:16 2011 +0100
+++ b/Modules/selectmodule.c	Fri Jun 10 23:35:14 2011 +0200
@@ -110,7 +110,7 @@
 #if defined(_MSC_VER)
         max = 0;                             /* not used for Win32 */
 #else  /* !_MSC_VER */
-        if (v < 0 || v >= FD_SETSIZE) {
+        if (!_PyIsSelectable_fd(v)) {
             PyErr_SetString(PyExc_ValueError,
                         "filedescriptor out of range in select()");
             goto finally;
@@ -160,13 +160,6 @@
     for (j = 0; fd2obj[j].sentinel >= 0; j++) {
         fd = fd2obj[j].fd;
         if (FD_ISSET(fd, set)) {
-#ifndef _MSC_VER
-            if (fd > FD_SETSIZE) {
-                PyErr_SetString(PyExc_SystemError,
-               "filedescriptor out of range returned in select()");
-                goto finally;
-            }
-#endif
             o = fd2obj[j].obj;
             fd2obj[j].obj = NULL;
             /* transfer ownership */
diff -r e572a97a1bd1 Modules/socketmodule.c
--- a/Modules/socketmodule.c	Fri Jun 10 19:05:16 2011 +0100
+++ b/Modules/socketmodule.c	Fri Jun 10 23:35:14 2011 +0200
@@ -469,18 +469,14 @@
 #include <sys/poll.h>
 #endif
 
-#ifdef Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE
-/* Platform can select file descriptors beyond FD_SETSIZE */
-#define IS_SELECTABLE(s) 1
-#elif defined(HAVE_POLL)
+#ifdef HAVE_POLL
 /* Instead of select(), we'll use poll() since poll() works on any fd. */
 #define IS_SELECTABLE(s) 1
 /* Can we call select() with this socket without a buffer overrun? */
 #else
-/* POSIX says selecting file descriptors beyond FD_SETSIZE
-   has undefined behaviour.  If there's no timeout left, we don't have to
-   call select, so it's a safe, little white lie. */
-#define IS_SELECTABLE(s) ((s)->sock_fd < FD_SETSIZE || s->sock_timeout <= 0.0)
+/* If there's no timeout left, we don't have to call select, so it's a safe,
+ * little white lie. */
+#define IS_SELECTABLE(s) (_PyIsSelectable_fd((s)->sock_fd) || s->sock_timeout <= 0.0)
 #endif
 
 static PyObject*
-------------- next part --------------
diff -r e572a97a1bd1 Lib/test/test_ossaudiodev.py
--- a/Lib/test/test_ossaudiodev.py	Fri Jun 10 19:05:16 2011 +0100
+++ b/Lib/test/test_ossaudiodev.py	Fri Jun 10 23:44:08 2011 +0200
@@ -170,6 +170,14 @@
             pass
         self.assertTrue(dsp.closed)
 
+    def test_on_closed(self):
+        dsp = ossaudiodev.open('w')
+        dsp.close()
+        self.assertRaises(ValueError, dsp.fileno)
+        self.assertRaises(ValueError, dsp.read, 1)
+        self.assertRaises(ValueError, dsp.write, b'x')
+        self.assertRaises(ValueError, dsp.writeall, b'x')
+
 
 def test_main():
     try:
diff -r e572a97a1bd1 Modules/ossaudiodev.c
--- a/Modules/ossaudiodev.c	Fri Jun 10 19:05:16 2011 +0100
+++ b/Modules/ossaudiodev.c	Fri Jun 10 23:44:08 2011 +0200
@@ -213,6 +213,21 @@
  * Helper functions
  */
 
+/* Check if a given file descriptor is valid (i.e. hasn't been closed).
+ * If true, return 1. Otherwise, raise ValueError and return 0.
+ */
+static int _is_fd_valid(int fd)
+{
+    /* the FD is set to -1 in oss_close()/oss_mixer_close() */
+    if (fd >= 0) {
+        return 1;
+    } else {
+        PyErr_SetString(PyExc_ValueError,
+                        "Operation on closed OSS device.");
+        return 0;
+    }
+}
+
 /* _do_ioctl_1() is a private helper function used for the OSS ioctls --
    SNDCTL_DSP_{SETFMT,CHANNELS,SPEED} -- that that are called from C
    like this:
@@ -300,6 +315,9 @@
 static PyObject *
 oss_nonblock(oss_audio_t *self, PyObject *unused)
 {
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     /* Hmmm: it doesn't appear to be possible to return to blocking
        mode once we're in non-blocking mode! */
     if (ioctl(self->fd, SNDCTL_DSP_NONBLOCK, NULL) == -1)
@@ -311,6 +329,9 @@
 static PyObject *
 oss_setfmt(oss_audio_t *self, PyObject *args)
 {
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_1(self->fd, args, "setfmt", SNDCTL_DSP_SETFMT);
 }
 
@@ -318,6 +339,10 @@
 oss_getfmts(oss_audio_t *self, PyObject *unused)
 {
     int mask;
+
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     if (ioctl(self->fd, SNDCTL_DSP_GETFMTS, &mask) == -1)
         return PyErr_SetFromErrno(PyExc_IOError);
     return PyLong_FromLong(mask);
@@ -326,30 +351,45 @@
 static PyObject *
 oss_channels(oss_audio_t *self, PyObject *args)
 {
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_1(self->fd, args, "channels", SNDCTL_DSP_CHANNELS);
 }
 
 static PyObject *
 oss_speed(oss_audio_t *self, PyObject *args)
 {
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_1(self->fd, args, "speed", SNDCTL_DSP_SPEED);
 }
 
 static PyObject *
 oss_sync(oss_audio_t *self, PyObject *args)
 {
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_0(self->fd, args, "sync", SNDCTL_DSP_SYNC);
 }
 
 static PyObject *
 oss_reset(oss_audio_t *self, PyObject *args)
 {
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_0(self->fd, args, "reset", SNDCTL_DSP_RESET);
 }
 
 static PyObject *
 oss_post(oss_audio_t *self, PyObject *args)
 {
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_0(self->fd, args, "post", SNDCTL_DSP_POST);
 }
 
@@ -364,6 +404,9 @@
     char *cp;
     PyObject *rv;
 
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     if (!PyArg_ParseTuple(args, "i:read", &size))
         return NULL;
     rv = PyBytes_FromStringAndSize(NULL, size);
@@ -391,6 +434,9 @@
     char *cp;
     int rv, size;
 
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     if (!PyArg_ParseTuple(args, "y#:write", &cp, &size)) {
         return NULL;
     }
@@ -422,6 +468,9 @@
        mode, the behaviour of write() and writeall() from Python is
        indistinguishable. */
 
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     if (!PyArg_ParseTuple(args, "y#:write", &cp, &size))
         return NULL;
 
@@ -489,6 +538,9 @@
 static PyObject *
 oss_fileno(oss_audio_t *self, PyObject *unused)
 {
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     return PyLong_FromLong(self->fd);
 }
 
@@ -503,6 +555,9 @@
     int fmt, channels, rate;
     PyObject * rv;                    /* return tuple (fmt, channels, rate) */
 
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     if (!PyArg_ParseTuple(args, "iii|i:setparameters",
                           &wanted_fmt, &wanted_channels, &wanted_rate,
                           &strict))
@@ -593,6 +648,9 @@
     audio_buf_info ai;
     int nchannels=0, ssize=0;
 
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     if (_ssize(self, &nchannels, &ssize) < 0 || !nchannels || !ssize) {
         PyErr_SetFromErrno(PyExc_IOError);
         return NULL;
@@ -612,6 +670,9 @@
     audio_buf_info ai;
     int nchannels=0, ssize=0;
 
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     if (_ssize(self, &nchannels, &ssize) < 0 || !nchannels || !ssize) {
         PyErr_SetFromErrno(PyExc_IOError);
         return NULL;
@@ -632,6 +693,9 @@
     audio_buf_info ai;
     int nchannels=0, ssize=0;
 
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     if (_ssize(self, &nchannels, &ssize) < 0 || !nchannels || !ssize) {
         PyErr_SetFromErrno(PyExc_IOError);
         return NULL;
@@ -649,6 +713,9 @@
     count_info info;
     int req;
 
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     if (self->mode == O_RDONLY)
         req = SNDCTL_DSP_GETIPTR;
     else
@@ -679,6 +746,9 @@
 static PyObject *
 oss_mixer_fileno(oss_mixer_t *self, PyObject *unused)
 {
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     return PyLong_FromLong(self->fd);
 }
 
@@ -687,6 +757,9 @@
 static PyObject *
 oss_mixer_controls(oss_mixer_t *self, PyObject *args)
 {
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_1_internal(self->fd, args, "controls",
         SOUND_MIXER_READ_DEVMASK);
 }
@@ -694,6 +767,9 @@
 static PyObject *
 oss_mixer_stereocontrols(oss_mixer_t *self, PyObject *args)
 {
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_1_internal(self->fd, args, "stereocontrols",
         SOUND_MIXER_READ_STEREODEVS);
 }
@@ -701,6 +777,9 @@
 static PyObject *
 oss_mixer_reccontrols(oss_mixer_t *self, PyObject *args)
 {
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_1_internal(self->fd, args, "reccontrols",
         SOUND_MIXER_READ_RECMASK);
 }
@@ -710,6 +789,9 @@
 {
     int channel, volume;
 
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     /* Can't use _do_ioctl_1 because of encoded arg thingy. */
     if (!PyArg_ParseTuple(args, "i:get", &channel))
         return NULL;
@@ -730,6 +812,9 @@
 {
     int channel, volume, leftVol, rightVol;
 
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     /* Can't use _do_ioctl_1 because of encoded arg thingy. */
     if (!PyArg_ParseTuple(args, "i(ii):set", &channel, &leftVol, &rightVol))
         return NULL;
@@ -755,6 +840,9 @@
 static PyObject *
 oss_mixer_get_recsrc(oss_mixer_t *self, PyObject *args)
 {
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_1_internal(self->fd, args, "get_recsrc",
         SOUND_MIXER_READ_RECSRC);
 }
@@ -762,6 +850,9 @@
 static PyObject *
 oss_mixer_set_recsrc(oss_mixer_t *self, PyObject *args)
 {
+    if (!_is_fd_valid(self->fd))
+        return NULL;
+
     return _do_ioctl_1(self->fd, args, "set_recsrc",
         SOUND_MIXER_WRITE_RECSRC);
 }

From report at bugs.python.org  Fri Jun 10 23:46:11 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 10 Jun 2011 21:46:11 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1307742371.08.0.150558160157.issue12287@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22284/oss_select.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Fri Jun 10 23:46:22 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 10 Jun 2011 21:46:22 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1307742382.37.0.753581866368.issue12287@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22301/oss_check_closed.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Fri Jun 10 23:50:28 2011
From: report at bugs.python.org (Darren Dale)
Date: Fri, 10 Jun 2011 21:50:28 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1307742628.11.0.887362625857.issue11610@psf.upfronthosting.co.za>


Changes by Darren Dale <dsdale24 at gmail.com>:


----------
components: +Library (Lib) -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Fri Jun 10 23:54:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Jun 2011 21:54:42 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <BANLkTikUSiAMqgJa941ZW7o97mrkqTEHLg@mail.gmail.com>
Message-ID: <1307742874.3653.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Two patches attached:
> - a patch checking that the ossaudiodev object isn't closed
> - a patch adding _PyIsSelectable_fd()

In oss_check_closed.diff, you might want to add tests for the other
methods as well. Otherwise, looks good!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Fri Jun 10 23:57:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jun 2011 21:57:27 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1307743047.69.0.962138675116.issue12287@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Comments on is_selectable.diff.

> +#define IS_SELECTABLE(s) (_PyIsSelectable_fd((s)->sock_fd) || s->sock_timeout <= 0.0)

You may add parenthesis around the second s (even if it's unrelated to this issue and not a regression of your patch).

> +#ifdef Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE
> ...
>  #if defined(_MSC_VER)
>          max = 0;                 /* not used for Win32 */

I still don't understand these checks: why not testing simply for #ifdef MS_WINDOWS? MinGW or Cygwin have another implementation of select() which is more limited?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Sat Jun 11 00:01:24 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 10 Jun 2011 22:01:24 +0000
Subject: [issue12316] test_signal: test_sigwait_thread
	failure on FreeBSD 6.4 buildbot
In-Reply-To: <1307743284.62.0.757542886858.issue12316@psf.upfronthosting.co.za>
Message-ID: <1307743284.62.0.757542886858.issue12316@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

http://www.python.org/dev/buildbot/all/builders/x86 FreeBSD 6.4 3.x/builds/1570/steps/test/logs/stdio

"""
[ 29/356] test_signal
Fatal error 'mutex is on list' at line 540 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 22)
test test_signal failed -- Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_signal.py", line 669, in test_sigwait_thread
    self.check_sigwait(test, signal.SIGUSR1)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_signal.py", line 632, in check_sigwait
    self.assertEqual(os.waitpid(pid, 0), (pid, 0))
AssertionError: Tuples differ: (50592, 134) != (50592, 0)

First differing element 1:
134
0

- (50592, 134)
?         ^^^

+ (50592, 0)
?         ^
"""


Fatal error 'mutex is on list' at line 540 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 22)

In a multi-threaded program, we're only allowed to call async-safe functions between fork() and exec() in the child process (well, taken literaly this means we shouldn't run Python at all after fork...). It looks like FreeBSD 6.4 doesn't like new threads after fork() :
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-03/msg00108.html

test_sigwait_thread should either be skipped on FreeBSD 6 (it seems to pass on FreeBSD 7), or removed altogether.

----------
components: Tests
messages: 138138
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: 
  test_signal: test_sigwait_thread
  failure on FreeBSD 6.4 buildbot
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12316>
_______________________________________

From report at bugs.python.org  Sat Jun 11 00:17:02 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 10 Jun 2011 22:17:02 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1307744222.37.0.686864737866.issue12287@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> In oss_check_closed.diff, you might want to add tests for the other
> methods as well.

I've added checks for other methods (not all of them, there are quite a few). I've also added a check for the mixer object.

> You may add parenthesis around the second s

Done.

> I still don't understand these checks

Me neither.
Since I don't know anything about Windows, I tried to keep the existing checks, but this doens't make much sense to me. Maybe Amaury can shed a light on this?

----------
Added file: http://bugs.python.org/file22326/is_selectable.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Sat Jun 11 00:17:35 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 10 Jun 2011 22:17:35 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1307744255.49.0.683638424213.issue12287@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file22327/oss_check_closed.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Sat Jun 11 00:17:44 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 10 Jun 2011 22:17:44 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1307744264.85.0.865205818992.issue12287@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22324/is_selectable.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Sat Jun 11 00:17:53 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 10 Jun 2011 22:17:53 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1307744273.78.0.358187334078.issue12287@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22325/oss_check_closed.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Sat Jun 11 00:22:24 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 10 Jun 2011 22:22:24 +0000
Subject: [issue12313] make install misses packaging module
In-Reply-To: <1307722082.95.0.13819638115.issue12313@psf.upfronthosting.co.za>
Message-ID: <1307744544.97.0.264601525664.issue12313@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Listing all those directories to the Makefile does seem very brittle and will certainly be a maintenance hassle.  OTOH, there is something to be said for being explicit about what gets installed.  I suppose you could add the find step to ./configure and pass the list into the Makefile.  Dunno if that is really is a good idea, though.

In any case, if a reminder isn't already there, perhaps one should be added to the devguide or packaging docs about this when adding test directories.

Also you may want to add some of the packaging test directories to those excluded in the calls to compileall.py a little further down in the libinstall target.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12313>
_______________________________________

From report at bugs.python.org  Sat Jun 11 00:36:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jun 2011 22:36:06 +0000
Subject: [issue12316] test_signal: test_sigwait_thread failure on FreeBSD 6.4
	buildbot
In-Reply-To: <1307743284.62.0.757542886858.issue12316@psf.upfronthosting.co.za>
Message-ID: <1307745366.26.0.591254125335.issue12316@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> In a multi-threaded program, we're only allowed to call async-safe
> functions between fork() and exec() in the child process

Oh, I don't know that. The test should be modified to create a new clean Python process using subprocess to run the test.

----------
title: 
Now:
  test_signal: test_sigwait_thread failure on FreeBSD 6.4 buildbot
Was:
  test_signal: test_sigwait_thread
  failure on FreeBSD 6.4 buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12316>
_______________________________________

From report at bugs.python.org  Sat Jun 11 01:45:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 10 Jun 2011 23:45:50 +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: <1307749550.99.0.594252853617.issue11898@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

should *not* be reopened. Sorry for omission of 'not'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Sat Jun 11 03:03:14 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jun 2011 01:03:14 +0000
Subject: [issue12188] PEP 7 (or guide) add C style policies and explanation
In-Reply-To: <1306433972.91.0.882585972593.issue12188@psf.upfronthosting.co.za>
Message-ID: <1307754194.63.0.0256104345777.issue12188@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

We have a second item for the PEP (or Guide) section (but I think I prefer in the PEP so as to have one place to look for such things.).
So I changed the title a bit.

On 6/10/2011 3:49 PM, Guido van Rossum wrote:
> On Wed, Jun 8, 2011 at 8:12 AM, Nick Coghlan<ncoghlan at gmail.com>  
>> I actually thought Brett's rationale in the checkin comment was
>> reasonable (if you get in the habit of putting constants on the left,
>> then the classic "'=' instead of '=='" typo is a compiler error
>> instead of a reassignment).

[I understand this rationale too; I forget what I actually did when I was writing C.]

> I really like consistency across the code base. I really don't like
> constant-on-the-left, and it's basically not used in the current
> codebase. Please be consistent and don't start using it.

[I suspect I did this.]
 
>> Call it a +0 in favour of letting people put constants on the left in
>> C code if they prefer it that way, so long as any given if/elif chain
>> is consistent in the style it uses.
> 
> Sorry, I give it a -1. (I'd like to be able to read the codebase still... :-)

I bet there will be more things for a new section.

----------
title: PEP 7, C style: add ++ policy and explanation -> PEP 7 (or guide) add C style policies and explanation
type: feature request -> 
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12188>
_______________________________________

From report at bugs.python.org  Sat Jun 11 03:53:55 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jun 2011 01:53:55 +0000
Subject: [issue12260] Make install default to user site-packages
In-Reply-To: <1307121861.82.0.570588263731.issue12260@psf.upfronthosting.co.za>
Message-ID: <1307757235.92.0.302723221678.issue12260@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In my Winxp machine, I can add and delete directories in python32/Lib/site-packages (all-users installation) from my user account. That is what I expect and want the default to be, not the Terry/whatever that I have never used (or the admin/whatever if I happen to install as admin.)

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12260>
_______________________________________

From report at bugs.python.org  Sat Jun 11 03:56:17 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jun 2011 01:56:17 +0000
Subject: [issue12261] urllib.parse docs still refer to urlparse
In-Reply-To: <1307129696.46.0.265723026729.issue12261@psf.upfronthosting.co.za>
Message-ID: <1307757377.59.0.66792659104.issue12261@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I believe this is ready to apply.

----------
nosy: +terry.reedy
stage:  -> commit review
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12261>
_______________________________________

From report at bugs.python.org  Sat Jun 11 04:04:23 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jun 2011 02:04:23 +0000
Subject: [issue12272] Python 2.7.1 version conflict for package "Tcl" on
	Windows 7
In-Reply-To: <1307394575.29.0.810712086892.issue12272@psf.upfronthosting.co.za>
Message-ID: <1307757863.88.0.161836909953.issue12272@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Martin, any ideas?

Jack, I would wipe out the tcl directory and rerun the 2.7.1 installer, selecting just the tk/tcl/idle option. I have trouble believe that every 2.7.1 install on win7 is bad.

----------
nosy: +loewis, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12272>
_______________________________________

From report at bugs.python.org  Sat Jun 11 04:17:35 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jun 2011 02:17:35 +0000
Subject: [issue12276] 3.x ignores sys.tracebacklimit=0
In-Reply-To: <1307436501.83.0.59684150491.issue12276@psf.upfronthosting.co.za>
Message-ID: <1307758655.32.0.337613193908.issue12276@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Either code or doc must change (with 'version changed' note). Doc: "The default is 1000. When set to 0 or less, all traceback information is suppressed and only the exception type and value are printed."

Christian's patch: "values <= 0 are replaced with a default value to avoid infinite recursion and other issues." Default is 1000.

I do not see the logic of changing 'nothing' to 'everything'. I am puzzled how printing nothing causes infinite recursion.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +christian.heimes, docs at python, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12276>
_______________________________________

From report at bugs.python.org  Sat Jun 11 04:37:33 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jun 2011 02:37:33 +0000
Subject: [issue12299] Stop documenting functions added by site as builtins
In-Reply-To: <1307636270.04.0.997555638345.issue12299@psf.upfronthosting.co.za>
Message-ID: <1307759853.31.0.687776416176.issue12299@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In the 3.2.0 doc, quit and exit (which are unnecessary and nearly useless) are already in the site-variables section (where I think they should be), not in builtin funcs. Did someone move them since? If so, you should discuss rather than just revert. 

The extremely useful help() is documented with builtin funcs, where beginners can it easily. It is used (frequently) in interactive mode. It is documented as being added by site. It could *also* be listed with quit and exit in the site additions section. Anyone sophisticated (foolish) enough to start interactive mode with -S (a bit hard on Windows) should know the consequences. I am opposed to removing the current entry.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12299>
_______________________________________

From report at bugs.python.org  Sat Jun 11 04:40:37 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jun 2011 02:40:37 +0000
Subject: [issue12300] Document pydoc.help
In-Reply-To: <1307636340.19.0.379742788124.issue12300@psf.upfronthosting.co.za>
Message-ID: <1307760037.59.0.823330688744.issue12300@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

There is already a link to the main entry, which is where I think it should be.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12300>
_______________________________________

From report at bugs.python.org  Sat Jun 11 04:43:07 2011
From: report at bugs.python.org (higery)
Date: Sat, 11 Jun 2011 02:43:07 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1307760187.37.0.749183113065.issue828450@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Removed 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  Sat Jun 11 04:43:15 2011
From: report at bugs.python.org (higery)
Date: Sat, 11 Jun 2011 02:43:15 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1307760195.83.0.084806480061.issue828450@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Removed 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  Sat Jun 11 04:44:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jun 2011 02:44:24 +0000
Subject: [issue12301] Use :data:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1307760264.33.0.157193917169.issue12301@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Links are good ;-).

----------
nosy: +terry.reedy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12301>
_______________________________________

From report at bugs.python.org  Sat Jun 11 04:57:49 2011
From: report at bugs.python.org (higery)
Date: Sat, 11 Jun 2011 02:57:49 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1307761069.52.0.857562691397.issue828450@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

I just recreated this patch against version 2.7, so I'm not sure it can be applied to all the listed versions.

Note: there still are two pathes, one for sdist.py and another for test_sdist.py

----------
Added file: http://bugs.python.org/file22328/test_manifest_reading_sdist.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Sat Jun 11 09:11:31 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 11 Jun 2011 07:11:31 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1307776291.64.0.133148733288.issue11610@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

It doesn't work with staticmethod:

>>> import abc
>>> 
>>> class C(metaclass=abc.ABCMeta):
...     @staticmethod
...     @abc.abstractmethod
...     def foo(x):
...             raise NotImplementedError()
... 
>>> class D(C):
...     @staticmethod
...     def foo(x):
...             return x + 1
... 
>>> D()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't instantiate abstract class D with abstract methods foo.__func__
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sat Jun 11 11:23:55 2011
From: report at bugs.python.org (Darren Dale)
Date: Sat, 11 Jun 2011 09:23:55 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1307776291.64.0.133148733288.issue11610@psf.upfronthosting.co.za>
Message-ID: <BANLkTikwiSxLdCY83yn7hM46Jjr-Tu3zJg@mail.gmail.com>


Darren Dale <dsdale24 at gmail.com> added the comment:

On Sat, Jun 11, 2011 at 3:11 AM, Daniel Urban <report at bugs.python.org> wrote:
>
> Daniel Urban <urban.dani+py at gmail.com> added the comment:
>
> It doesn't work with staticmethod:
>
>>>> import abc
>>>>
>>>> class C(metaclass=abc.ABCMeta):
> ... ? ? @staticmethod
> ... ? ? @abc.abstractmethod
> ... ? ? def foo(x):
> ... ? ? ? ? ? ? raise NotImplementedError()
> ...
>>>> class D(C):
> ... ? ? @staticmethod
> ... ? ? def foo(x):
> ... ? ? ? ? ? ? return x + 1
> ...
>>>> D()
> Traceback (most recent call last):
> ?File "<stdin>", line 1, in <module>
> TypeError: Can't instantiate abstract class D with abstract methods foo.__func__

You still need to use @abc.abstractstaticmethod.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sat Jun 11 11:59:04 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 11 Jun 2011 09:59:04 +0000
Subject: [issue12310] Segfault in test_multiprocessing
In-Reply-To: <1307697113.9.0.00979334615642.issue12310@psf.upfronthosting.co.za>
Message-ID: <1307786344.15.0.396048147634.issue12310@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I think it might be related to Issue #6721.

Using a mutex/condition variable after fork (from the child process) is unsafe: it can lead to deadlocks, and on OS-X, it seems like it can lead to segfaults.

Normally, Queue's synchronization primitives are reinitialized after fork, see Queue._after_fork() method.

But here, what happens is the following (well, that's an hypothesis):

Lib/multiprocessing/process.py", line 270 in _bootstrap
:
        _current_process = self
        util._finalizer_registry.clear()
        util._run_after_forkers()

- the old _current_process' reference count drops to zero
- it's deallocated, and since it holds the last reference to a Queue, the queue is finalized
- as a consequence, the Queue._finalize_close() callback (registered through a Finalize object) is called
- Queue._finalize_close() tries to acquire, signal and release the _notempty Condition, but the Condition hasn't been reinitialized yet, because util._run_after_forkers() is called 2 lines below
- segfault

It's probably been triggered by Antoine's patches, but I'm pretty sure this bug has always been there.

I think that moving util._run_after_forkers() up 2 lines should fix the segfaults, but with that change test_number_of_objects fails (I didn't investigate why).

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12310>
_______________________________________

From report at bugs.python.org  Sat Jun 11 13:32:35 2011
From: report at bugs.python.org (Graham Wideman)
Date: Sat, 11 Jun 2011 11:32:35 +0000
Subject: [issue11553] Docs for: import, packages, site.py, .pth files
In-Reply-To: <1300189190.68.0.0305569633639.issue11553@psf.upfronthosting.co.za>
Message-ID: <1307791955.47.0.327332908658.issue11553@psf.upfronthosting.co.za>


Graham Wideman <initcontact at grahamwideman.com> added the comment:

Hi Eric,  Thanks for starting to review this, and your responses are encouraging. Some comments inline below.

FWIW, along the way I accumulated my own notes on this topic, on some pages here:

grahamwideman.wikispaces.com
(Left navigation panel...)
Software development > Python > Organization for common modules

Might be of interest as feedback on the digging process I needed in order to get some clarity on these issues, and also shows my references.

>> Exactly what variants of arguments are possible, and what are their effects?
>Does http://docs.python.org/dev/library/functions#__import__ help? Does http://docs.python.org/dev/library/importlib ?

Well somewhat overkill -- because the matter of interest was args for from... and import, while the docs you mention are for more complicated underlying functions. (Interesting nonetheless.)

>> Current docs are unclear on points such as:
>> -- is __init__.py needed on subpackage directories?
>Yes, it always has.  I think there was some discussion about removing them in py3k, but this was rejected.
I came to same conclusion.. but have seen it described otherwise (in at least one book), so good to state this explicitly.

>> -- the __all__ variable: Does it act generally to limit visibility of a
>> module or package's attributes, or does pertain only to the
>> 'from...import *' statement?
> Both. 

I'm pretty sure that's not correct -- pretty sure that __all__ only specifies what's included in from...import *, and does not prevent access via from...import specific_attrib.  But I may have tested incorrectly.
                                                                                               
>> Seriously misleading discussion of .pth files.  [snip]
>Agreed. 

Cool -- I think it's well worth fixing this area for sure!

>> In addsitepackages(), the library directory for Windows (the else clause)
>> is shown as lower-case 'lib' instead of 'Lib'.
>I don?t see any else clause in the 2.7 or 3.3 code.  Otherwise you?re right.

Sorry, the lowecase 'lib' issue is in 
  getsitepackages()... 
  if sys.platform in(...) ... 
  else:...
    sitepackages.append(os.path.join(prefix, "lib", "site-packages"))

>> sys
>> Could helpfully point to a discussion of the typical items to
>> be found in sys.path under normal circumstances
>Hm, this would be very platform-specific.  What use cases would that help?

It would demystify how python already knows how to find various things under vanilla circumstances.

>> 'Installing Python Modules' document
>> "Windows has no concept of a user?s home directory, " and so on.
>The author probably meant that there was no $HOME environment variable, ~ shortcut and all that.

Fair enough, but in actuality there *is* a user-specific location (on Windows) examined by site.py, which is in %APPDATA%\Python\.

>> For Windows suggests 'prefix' (default: C:\Python) as an installation directory.
>> This is indeed one of the possible 'site-package' directories, but surely it is
>> deprecated in favor of C:\Python\Lib\site-packages, which this section does not mention.
>Don?t confuse the prefix and the install dir.  The directory for Python modules is computed as prefix + Lib/site-packages.

Currently, under "Alternate installation: Windows (the prefix scheme)", it says:
    python setup.py install --prefix="\Temp\Python"
    to install modules to the \Temp\Python directory on the current drive.
Does this really mean "install modules to \Temp\Python\Lib\site-packages"?
(And as a side point, surely installing under the Temp directory is a strange location to pick for an example?)

>That was my initial feeback; I think I?ve covered all of your points. 
Looking forward!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11553>
_______________________________________

From report at bugs.python.org  Sat Jun 11 14:09:03 2011
From: report at bugs.python.org (Darren Dale)
Date: Sat, 11 Jun 2011 12:09:03 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <BANLkTikwiSxLdCY83yn7hM46Jjr-Tu3zJg@mail.gmail.com>
Message-ID: <BANLkTikKGepSW0haUy-aYiLGft5L1MM31Q@mail.gmail.com>


Darren Dale <dsdale24 at gmail.com> added the comment:

[...]
>> Traceback (most recent call last):
>> ?File "<stdin>", line 1, in <module>
>> TypeError: Can't instantiate abstract class D with abstract methods foo.__func__
>
> You still need to use @abc.abstractstaticmethod.

Thinking about this some more, I think the error you found should be
considered a problem. The issue is with the descriptor access itself:
In class C we inspect the staticmethod instance in the namespace dict
passed to ABCMeta and find foo's abstract __func__. But later, ABCMeta
identifies C as a base of D, identifies C.foo.__func__ from
C.__abstractmethods__, then does a getattr on the formative D class.
D.__dict__['foo'] is a descriptor, which when accessed as D.foo
returns D.__dict__['foo'].__func__ (as opposed to the other
descriptors we have been discussing, where descriptor "get" access is
only invoked by an instance of the class). ABCMeta needs to inspect
the descriptor itself, not whatever the descriptor wants to return
when accessed. We can't use D.__dict__ to access the foo descriptor,
since some other base class of D may have provided the concrete
implementation of foo. Does anyone know another way to search the MRO
and return the foo descriptor?

You helped bring up another point: all functions are descriptors,
since they all have __get__ methods. That means every method is going
to be inspected for abstract members. Is this a problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sat Jun 11 14:23:13 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 11 Jun 2011 12:23:13 +0000
Subject: [issue11553] Docs for: import, packages, site.py, .pth files
In-Reply-To: <1300189190.68.0.0305569633639.issue11553@psf.upfronthosting.co.za>
Message-ID: <1307794993.88.0.982938292143.issue11553@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks for getting started with such a detailed review on this Graham. We've known the documentation in this area has been flawed for a long time, but actually *fixing* seemed like such a big task that it has tended to get pushed to the bottom of our respective to-do lists.

And so as things have been tweaked, the already flawed documentation has fallen even further out of date (as it wasn't always clear where updates should be included).

Simply breaking it down into a smaller list of easier to tackle problems is a big step towards getting something done about it.

A couple of specific notes:

__all__ only affects import *, and may also affect documentation tools (e.g. pydoc will respect __all__ when deciding what to display). It has no effect on attribute retrieval from modules.

pkgutil.extend_path() is used to modify pkg.__path__ attributes, *not* sys.path. It is used to allow a single package to span multiple directories, forming the basis for "namespace packages" (see http://www.python.org/dev/peps/pep-0382/#namespace-packages-today). 

Packages are technically a kind of module, but we're somewhat inconsistent in our use of the term "module". Sometimes it means all kinds of modules (frozen, builtin, extension, package, compiled, source), sometimes it means anything-but-a-package and occasionally it specifically means pure Python modules. In theory, context should make it clear which interpretation is intended. In practice, the boundaries between the first two meanings get a little blurry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11553>
_______________________________________

From report at bugs.python.org  Sat Jun 11 14:55:17 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 11 Jun 2011 12:55:17 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1307796917.62.0.113519414273.issue11610@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

inspect.getattr_static has the necessary logic to search for descriptors without invoking them.

However, it may be better to revert to the idea of pushing this functionality back onto the individual descriptors and have the problematic descriptors like property and staticmethod simply implement __isabstractmethod__ as a property.

property:
  @property
  def __isabstractmethod__(self):
    return (self.fget.__isabstractmethod__ or
            self.fset.__isabstractmethod__ or
            self.fdel.__isabstractmethod__)

staticmethod/classmethod:

  @property
  def __isabstractmethod__(self):
    return self.__func__.__isabstractmethod__

With this approach, the "one true way" to handle abstract descriptors would be to do:

  #instance method
  @abstractmethod
  def f(self):
    ...

  @property
  @abstractmethod
  def f(self):
    ...

  @classmethod
  @abstractmethod
  def f(self):
    ...

  @staticmethod
  @abstractmethod
  def f(self):
    ...

This wouldn't allow for the prettier error messages, but it's much cleaner than having ABCMeta trawling through class attribute dir() lists.

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sat Jun 11 15:21:22 2011
From: report at bugs.python.org (Darren Dale)
Date: Sat, 11 Jun 2011 13:21:22 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1307796917.62.0.113519414273.issue11610@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=hu9+Q4na7zSrbGvsff6=6p0n7Aw@mail.gmail.com>


Darren Dale <dsdale24 at gmail.com> added the comment:

On Sat, Jun 11, 2011 at 8:55 AM, Nick Coghlan <report at bugs.python.org> wrote:
>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> inspect.getattr_static has the necessary logic to search for descriptors without invoking them.

Unfortunately, we can't import inspect, even inside ABCMeta.__new__.

> However, it may be better to revert to the idea of pushing this functionality back onto the individual descriptors and have the problematic descriptors like property and staticmethod simply implement __isabstractmethod__ as a property.
>
> property:
> ?@property
> ?def __isabstractmethod__(self):
> ? ?return (self.fget.__isabstractmethod__ or
> ? ? ? ? ? ?self.fset.__isabstractmethod__ or
> ? ? ? ? ? ?self.fdel.__isabstractmethod__)
>
> staticmethod/classmethod:
>
> ?@property
> ?def __isabstractmethod__(self):
> ? ?return self.__func__.__isabstractmethod__

That's a good idea.

> With this approach, the "one true way" to handle abstract descriptors would be to do:
>
> ?#instance method
> ?@abstractmethod
> ?def f(self):
> ? ?...
>
> ?@property
> ?@abstractmethod
> ?def f(self):
> ? ?...
>
> ?@classmethod
> ?@abstractmethod
> ?def f(self):
> ? ?...
>
> ?@staticmethod
> ?@abstractmethod
> ?def f(self):
> ? ?...
>
> This wouldn't allow for the prettier error messages, but it's much cleaner than having ABCMeta trawling through class attribute dir() lists.

Those classes could conceivably do:

@property
def __abstractmethods__(self):
    return ("...", ...)

It would not be required, but if ABCMeta found it, it could use it.
Just a thought.

Darren

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sat Jun 11 16:26:37 2011
From: report at bugs.python.org (=?utf-8?q?Greg_S=C5=82odkowicz?=)
Date: Sat, 11 Jun 2011 14:26:37 +0000
Subject: [issue11553] Docs for: import, packages, site.py, .pth files
In-Reply-To: <1300189190.68.0.0305569633639.issue11553@psf.upfronthosting.co.za>
Message-ID: <1307802397.13.0.436680343949.issue11553@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/issue11553>
_______________________________________

From report at bugs.python.org  Sat Jun 11 17:24:37 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 11 Jun 2011 15:24:37 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1307805877.07.0.863087279512.issue12291@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Patch is now in my public sandbox on hg.python.org.

----------
hgrepos: +26

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sat Jun 11 17:32:36 2011
From: report at bugs.python.org (Graham Wideman)
Date: Sat, 11 Jun 2011 15:32:36 +0000
Subject: [issue11553] Docs for: import, packages, site.py, .pth files
In-Reply-To: <1300189190.68.0.0305569633639.issue11553@psf.upfronthosting.co.za>
Message-ID: <1307806356.98.0.910923288986.issue11553@psf.upfronthosting.co.za>


Graham Wideman <initcontact at grahamwideman.com> added the comment:

Hi Nick: Thanks for your additional points. Comments inline:

> __all__ only affects import *, and may also affect documentation tools (e.g. pydoc will respect __all__ when deciding what to display). It has no effect on attribute retrieval from modules.

That's indeed my understanding. So the doc (6. Simple statements) which says that __all__ determines the list of "public names" is a bit of a red herring.  Attributes are accessible (ie: public) regardless of whether on the __all__ list.  Instead the __all__ list establishes the list of names imported by *, and makes those names reference-able without a module prefix. (Plus gives hints about intent to doc tools.)

> pkgutil.extend_path() is used to modify pkg.__path__ attributes, *not* sys.path. 

Understood, and perhaps my point was obtuse.  I was pointing out that the doc for extend_path discusses .pkg entries which point to package dirs, and that this, it says, is like .pth files. I claim that an entry in a .pth files should NOT point to a package dir, but rather to one level up: to a dir that *contains* package dirs. (Pointing a .pth entry directly at a package dir will break package behavior by exposing the constituent modules to sys.path.)  Hence the doc for extend_path is misleadingly suggesting a wrong idea about .pth files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11553>
_______________________________________

From report at bugs.python.org  Sat Jun 11 17:38:57 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 11 Jun 2011 15:38:57 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1307806737.02.0.695448028195.issue12291@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

For some reason, "Create Patch" is failing with a

[Errno 2] No such file or directory: '/home/roundup/trackers/tracker/cpython/Doc/Makefile'

I've logged an issue on the meta tracker:

http://psf.upfronthosting.co.za/roundup/meta/issue405

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sat Jun 11 18:12:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 11 Jun 2011 16:12:39 +0000
Subject: [issue12310] Segfault in test_multiprocessing
In-Reply-To: <1307697113.9.0.00979334615642.issue12310@psf.upfronthosting.co.za>
Message-ID: <1307808759.44.0.0373389634555.issue12310@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Less disruptive approach:

        old_process = _current_process
        _current_process = self
        try:
            util._finalizer_registry.clear()
            util._run_after_forkers()
        finally:
            del old_process

This will delay finalization of the old process object until after _run_after_forkers() is executed, without (hopefully) messing with semantics.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12310>
_______________________________________

From report at bugs.python.org  Sat Jun 11 18:27:35 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 11 Jun 2011 16:27:35 +0000
Subject: [issue10115] Support accept4() for atomic setting of flags at socket
	creation
In-Reply-To: <1307447139.45.0.440649691058.issue10115@psf.upfronthosting.co.za>
Message-ID: <BANLkTikWi0xkU1oo-rHN8Ga+1uCawGckOQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

No one seems to object, and since this approach has been suggested by
Martin and  is consistent with the posix module's policy (i.e. a thin
wrapper around the underlying syscall), I guess you can go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Sat Jun 11 18:30:22 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 11 Jun 2011 16:30:22 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307744273.84.0.125642144441.issue12287@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=3OVspq5jNjLHsEfeZ=2vnjFY3yA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

For oss_check_closed.diff, should I apply it to default only or to every branch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Sat Jun 11 18:32:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 11 Jun 2011 16:32:46 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1307809966.62.0.364541737214.issue12287@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> For oss_check_closed.diff, should I apply it to default only or to
> every branch?

Only default I'd say.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Sat Jun 11 18:40:14 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 11 Jun 2011 16:40:14 +0000
Subject: [issue10897] UNIX mmap unnecessarily dup() file descriptor
In-Reply-To: <1307722526.89.0.276264925751.issue10897@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=tB9RyR+P8B06Rcarzj6sRcN2Zsg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Perhaps by adding some new argument to the mmap constructor? (dup_fd = True)

I don't really like the idea of exposing the FD duplication to the
user, because:
- it's an implementation detail
- it doesn't reflect any argument of the POSIX mmap version
- it should False by default

I really think that application code expecting to be able to resize
the mmap after closing the FD is broken, but I'm also a really strong
advocate of backward compatibility...
I don't see any satisfying solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10897>
_______________________________________

From report at bugs.python.org  Sat Jun 11 18:44:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 11 Jun 2011 16:44:21 +0000
Subject: [issue12315] Improve http.client.HTTPResponse.read documentation
In-Reply-To: <1307733776.17.0.904388798994.issue12315@psf.upfronthosting.co.za>
Message-ID: <1307810661.42.0.0880254876914.issue12315@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +orsenthil
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12315>
_______________________________________

From report at bugs.python.org  Sat Jun 11 18:44:46 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 11 Jun 2011 16:44:46 +0000
Subject: [issue12310] Segfault in test_multiprocessing
In-Reply-To: <1307697113.9.0.00979334615642.issue12310@psf.upfronthosting.co.za>
Message-ID: <1307810686.47.0.866020344207.issue12310@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Yes, I also tried this.
This fixed the test_multiprocessing failure, but I think it triggered a failure in test_concurrent_futures (didin't look in more detail).
Would it be possible to try this on the buildbot to see if it fixes the segfaults?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12310>
_______________________________________

From report at bugs.python.org  Sat Jun 11 18:54:27 2011
From: report at bugs.python.org (Darren Dale)
Date: Sat, 11 Jun 2011 16:54:27 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1307796917.62.0.113519414273.issue11610@psf.upfronthosting.co.za>
Message-ID: <BANLkTinh_uRdZSXf6edUAaUxRuWeaLvxXw@mail.gmail.com>


Darren Dale <dsdale24 at gmail.com> added the comment:

[...]
>
> This wouldn't allow for the prettier error messages, but it's much cleaner than having ABCMeta trawling through class attribute dir() lists.

I think there is another reason to do it this way. Suppose I have a
custom descriptor MyProperty that stores its getter as
MyProperty.my_fget. In this example:

class C:
    @property
    @abstractmethod
    def foo(self): return 1

class D:
    @MyProperty
    def foo(self): return 2

if ABCMeta determines C.foo.fget is abstract, it will not recognize
that D.foo.my_fget supplies the concrete implementation. MyProperty
may provide the same interface as property, it may even subclass
property, but there is no guarantee its implementation conforms to
property the way ABCMeta is expecting it to.

The downside to making __isabstractmethod__ a property is that if C
declares foo to be a read/write property, and D redefines foo as
read-only and concrete, ABCMeta will not recognize the oversight. That
seems a significant deficiency to me. I'm not sure how to proceed.

Darren

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sat Jun 11 18:58:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 11 Jun 2011 16:58:29 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <E1QVRVx-0007RK-DO@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d0952a2fb7bd by Charles-Fran?ois Natali in branch 'default':
Issue #12287: In ossaudiodev, check that the device isn't closed in several
http://hg.python.org/cpython/rev/d0952a2fb7bd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Sat Jun 11 19:14:32 2011
From: report at bugs.python.org (Yuri)
Date: Sat, 11 Jun 2011 17:14:32 +0000
Subject: [issue9098] MSYS build fails with `S_IXGRP' undeclared
In-Reply-To: <1277729031.36.0.263470334817.issue9098@psf.upfronthosting.co.za>
Message-ID: <1307812472.26.0.459175689465.issue9098@psf.upfronthosting.co.za>


Yuri <yuri at tsoft.com> added the comment:

I fixed all build problems on the current MinGW32. python.exe builds ok, but build fails since python.exe can't find some modules after this. Not sure why.

----------
keywords: +patch
nosy: +yurivict
Added file: http://bugs.python.org/file22329/python-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9098>
_______________________________________

From report at bugs.python.org  Sat Jun 11 20:01:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 11 Jun 2011 18:01:43 +0000
Subject: [issue11595] Miscellaneous bugs in cfg_to_args() utility function
In-Reply-To: <1300466317.84.0.72161184259.issue11595@psf.upfronthosting.co.za>
Message-ID: <E1QVSVC-0004Wi-8x@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 303e3693d634 by ?ric Araujo in branch 'default':
Move useful function to packaging.util.
http://hg.python.org/cpython/rev/303e3693d634

New changeset 06670bd0e59e by ?ric Araujo in branch 'default':
Fix assorted bugs in packaging.util.cfg_to_args (#11595).
http://hg.python.org/cpython/rev/06670bd0e59e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11595>
_______________________________________

From report at bugs.python.org  Sat Jun 11 20:01:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 11 Jun 2011 18:01:43 +0000
Subject: [issue11599] Useless error message when distutils fails compiling
In-Reply-To: <1300473236.84.0.248517729635.issue11599@psf.upfronthosting.co.za>
Message-ID: <E1QVSVC-0004Wi-9A@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3ba34c03f2fc by ?ric Araujo in branch 'default':
Adjust logging in packaging.util.spawn (related to #11599)
http://hg.python.org/cpython/rev/3ba34c03f2fc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11599>
_______________________________________

From report at bugs.python.org  Sat Jun 11 20:01:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 11 Jun 2011 18:01:45 +0000
Subject: [issue12240] Allow multiple setup_hooks
In-Reply-To: <1307026779.27.0.653754848212.issue12240@psf.upfronthosting.co.za>
Message-ID: <E1QVSVC-0004Wi-94@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5f0cd4844061 by ?ric Araujo in branch 'default':
Allow multiple setup hooks in packaging?s setup.cfg files (#12240).
http://hg.python.org/cpython/rev/5f0cd4844061

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12240>
_______________________________________

From report at bugs.python.org  Sat Jun 11 20:01:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Jun 2011 18:01:47 +0000
Subject: [issue12313] make install misses packaging module
In-Reply-To: <1307722082.95.0.13819638115.issue12313@psf.upfronthosting.co.za>
Message-ID: <1307815307.14.0.0877685843031.issue12313@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Also you may want to add some of the packaging test directories to
> those excluded in the calls to compileall.py a little further down in
> the libinstall target.

Ah, good one.  I guess doing this could have prevented http://hg.python.org/cpython/rev/9041520be581

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12313>
_______________________________________

From report at bugs.python.org  Sat Jun 11 20:04:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Jun 2011 18:04:20 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1307815460.34.0.146898244612.issue828450@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I just recreated this patch against version 2.7, so I'm not sure it
> can be applied to all the listed versions.
It?s okay, distutils in 2.7 and 3.x is very similar, I can port.

> Note: there still are two pathes, one for sdist.py and another for
> test_sdist.py
Why?  hg diff can create one patch for many files.  It?s a bit easier if you upload just one patch.  Anyway, it?s not an issue, just upload the missing patch for sdist.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Sat Jun 11 20:06:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Jun 2011 18:06:07 +0000
Subject: [issue11595] Miscellaneous bugs in cfg_to_args() utility function
In-Reply-To: <1300466317.84.0.72161184259.issue11595@psf.upfronthosting.co.za>
Message-ID: <1307815567.35.0.673692649574.issue11595@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks again!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11595>
_______________________________________

From report at bugs.python.org  Sat Jun 11 20:06:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Jun 2011 18:06:39 +0000
Subject: [issue11599] Useless error message when distutils fails compiling
In-Reply-To: <1300473236.84.0.248517729635.issue11599@psf.upfronthosting.co.za>
Message-ID: <1307815599.45.0.575884991116.issue11599@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I intend to ask on distutils-sig whether doing the change in distutils would break code.

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11599>
_______________________________________

From report at bugs.python.org  Sat Jun 11 20:08:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Jun 2011 18:08:19 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1307461733.49.0.987510653631.issue12279@psf.upfronthosting.co.za>
Message-ID: <1307815699.9.0.956405486391.issue12279@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I forgot one thing: setuptools? egg_info command does write a list of paths, so we can look at how it solved the problem with the RECORD and RESOURCES files.

Higery: Michael is willing to work with you on this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Sat Jun 11 20:09:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Jun 2011 18:09:18 +0000
Subject: [issue12240] Allow multiple setup_hooks
In-Reply-To: <1307026779.27.0.653754848212.issue12240@psf.upfronthosting.co.za>
Message-ID: <1307815758.94.0.0895117029851.issue12240@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Done.

----------
assignee: tarek -> eric.araujo
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12240>
_______________________________________

From report at bugs.python.org  Sat Jun 11 20:38:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Jun 2011 18:38:08 +0000
Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with
	VC Express
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1307817488.19.0.139971393235.issue7511@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Hmm, in http://bugs.python.org/issue7511#msg106420 Tarek appeared to
> be supportive of the patch.

I believe Martin has more knowledge about Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Sat Jun 11 21:18:14 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 11 Jun 2011 19:18:14 +0000
Subject: [issue12317] inspect.getabsfile() is not documented
Message-ID: <1307819894.17.0.481142115694.issue12317@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
assignee: giampaolo.rodola
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: inspect.getabsfile() is not documented
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/issue12317>
_______________________________________

From report at bugs.python.org  Sat Jun 11 21:52:05 2011
From: report at bugs.python.org (John Edmonds)
Date: Sat, 11 Jun 2011 19:52:05 +0000
Subject: [issue12169] Factor out common code for d2 commands register,
	upload and upload_docs
In-Reply-To: <1306255725.22.0.23750798807.issue12169@psf.upfronthosting.co.za>
Message-ID: <1307821925.06.0.164046773826.issue12169@psf.upfronthosting.co.za>


John Edmonds <PocketCookies2 at gmail.com> added the comment:

Here is the patch, re-written for the packaging module.

----------
Added file: http://bugs.python.org/file22330/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12169>
_______________________________________

From report at bugs.python.org  Sat Jun 11 22:56:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 11 Jun 2011 20:56:17 +0000
Subject: [issue9284] inspect.findsource() cannot find source for doctest code
In-Reply-To: <1279372617.05.0.528440876901.issue9284@psf.upfronthosting.co.za>
Message-ID: <E1QVVE7-0006s1-8B@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 527c40add91d by Benjamin Peterson in branch '2.7':
allow "fake" filenames in findsource (closes #9284)
http://hg.python.org/cpython/rev/527c40add91d

New changeset 6cc4579dca02 by Benjamin Peterson in branch '3.2':
allow "fake" filenames in findsource (closes #9284)
http://hg.python.org/cpython/rev/6cc4579dca02

New changeset f05affb0bb2a by Benjamin Peterson in branch 'default':
merge 3.2 (#9284)
http://hg.python.org/cpython/rev/f05affb0bb2a

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9284>
_______________________________________

From report at bugs.python.org  Sat Jun 11 23:56:34 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 11 Jun 2011 21:56:34 +0000
Subject: [issue12206] Documentation Std. Library 15.7.5 "LogRecord objects":
	Parameters: level(currently wrong) -> levelno (correct)
In-Reply-To: <1306666020.34.0.114942173152.issue12206@psf.upfronthosting.co.za>
Message-ID: <1307829394.01.0.981510053619.issue12206@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Attached is a simple patch clarifying that the level argument in the constructor maps to the two LogRecord attributes, levelno and levelname,

----------
keywords: +patch
Added file: http://bugs.python.org/file22331/patch12206.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12206>
_______________________________________

From report at bugs.python.org  Sun Jun 12 00:02:51 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 11 Jun 2011 22:02:51 +0000
Subject: [issue12318] list + tuple inconsistency
In-Reply-To: <1307829771.92.0.859008661902.issue12318@psf.upfronthosting.co.za>
Message-ID: <1307829771.92.0.859008661902.issue12318@psf.upfronthosting.co.za>


New submission from Filip Gruszczy?ski <gruszczy at gmail.com>:

You can do this:
>>> [1] + (1,)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only concatenate list (not "tuple") to list

But you can do this:

>>> result = [1]
>>> result += (1,)
>>> result
[1, 1]


Is it the expected behaviour, that += does implicit coercion?

----------
messages: 138185
nosy: gruszczy
priority: normal
severity: normal
status: open
title: list + tuple inconsistency
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12318>
_______________________________________

From report at bugs.python.org  Sun Jun 12 00:03:24 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 11 Jun 2011 22:03:24 +0000
Subject: [issue12318] list + tuple inconsistency
In-Reply-To: <1307829771.92.0.859008661902.issue12318@psf.upfronthosting.co.za>
Message-ID: <1307829804.75.0.0700904415088.issue12318@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Obviously first sentence should be "You can't do this:".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12318>
_______________________________________

From report at bugs.python.org  Sun Jun 12 00:04:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 11 Jun 2011 22:04:44 +0000
Subject: [issue12206] Documentation Std. Library 15.7.5 "LogRecord objects":
	Parameters: level(currently wrong) -> levelno (correct)
In-Reply-To: <1306666020.34.0.114942173152.issue12206@psf.upfronthosting.co.za>
Message-ID: <E1QVWIN-000764-3z@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bb6fe43191c0 by Vinay Sajip in branch '3.2':
Issue #12206: documentation for LogRecord constructor updated re. the level argument.
http://hg.python.org/cpython/rev/bb6fe43191c0

New changeset 596adf14914c by Vinay Sajip in branch 'default':
Merged documentation update for issue #12206.
http://hg.python.org/cpython/rev/596adf14914c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12206>
_______________________________________

From report at bugs.python.org  Sun Jun 12 00:06:59 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 11 Jun 2011 22:06:59 +0000
Subject: [issue12206] Documentation Std. Library 15.7.5 "LogRecord objects":
	Parameters: level(currently wrong) -> levelno (correct)
In-Reply-To: <1306666020.34.0.114942173152.issue12206@psf.upfronthosting.co.za>
Message-ID: <1307830019.21.0.477150305379.issue12206@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee: docs at python -> vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12206>
_______________________________________

From report at bugs.python.org  Sun Jun 12 00:49:22 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 11 Jun 2011 22:49:22 +0000
Subject: [issue12318] list + tuple inconsistency
In-Reply-To: <1307829771.92.0.859008661902.issue12318@psf.upfronthosting.co.za>
Message-ID: <1307832562.48.0.0805707665628.issue12318@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Yes, this is the expected behavior and yes, it is inconsistent.

It's been that way for a long while and Guido said he wouldn't do it again (it's in his list of regrets).  However, we're not going to break code by changing it (list.__iadd__ working like list.extend).

----------
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12318>
_______________________________________

From report at bugs.python.org  Sun Jun 12 01:32:51 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 11 Jun 2011 23:32:51 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1307835171.13.0.973771323328.issue11610@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Perhaps rather than changing ABCMeta, provide a base descriptor class that has __isabstractmethod__ implemented to calculate the abstractness.  Then property could use that, as could any of the other relevant descriptors we have around.  The __isabstractmethod__ attribute of the descriptor would itself need to be a data-descriptor (which property() is).  That would ensure that __isabstractmethod__ is not set directly on the descriptor instance.

I agree with Nick that it may be better to have the descriptor classes take care of managing __isabstractmethod__ themselves, instead of having ABCMeta compute it.  Special-casing ABCMeta to handle custom __isabstractmethod__ calculation for any specific type seems like something we should avoid.

Per your last message, if a specific descriptor has an abstract setter then the descriptor should be considered abstract.  If the implementation of that attribute is not a descriptor should it raise a TypeError?  If it is a descriptor but it does not have a setter, should it likewise fail?  I'm not so sure.  We already don't enforce types on abstract attributes.  You don't have to implement an abstractproperty with a property, an abstractstaticmethod with a staticmethod, nor an abstractclassmethod with a classmethod.  For that matter you don't have to implement an abstractmethod with a function.  It just has to be an object bound to the same name.  Should descriptors get special treatment over any other type that implements __isabstractmethod__?

That brings up a concern of mine.  I've found the name abstractmethod (specifically the "method" part) to be misleading.  Any attribute can be "abstract" and ABCMeta only cares about __isabstractmethod__.  Maybe having "method" in the name is meant to imply the expected use case?  I would rather they were called  __isabstractattribute__, and __abstractattributes__, which would be less confusing when using ABCs, particularly at first.  Having "attribute" in the name is nice, since it makes it clear we're talking about attributes, rather than other abstraction contexts.  Having a specific abstractmethod decorator is still good since we only decorate functions in an ABC.

I'm +1 for deprecating abstractproperty and really all the decorators except abstractmethod (if the use cases were addressed).  If abstractmethod were smart about on which object it sets __isabstractmethod__, the other decorators would be unnecessary;  and the order in which you decorate would not matter as much.  The other decorators could become simple wrappers around abstractmethod if we felt the need to keep them around.  It's nice that the decorators say with what you are expecting to replace them, but you can get that by using the corresponding normal decorators.

----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun Jun 12 01:34:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Jun 2011 23:34:21 +0000
Subject: [issue12310] Segfault in test_multiprocessing
In-Reply-To: <1307810686.47.0.866020344207.issue12310@psf.upfronthosting.co.za>
Message-ID: <1307835256.19703.1.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Would it be possible to try this on the buildbot to see if it fixes
> the segfaults?

You can fork cpython, modify the code, and run a custom buildbot on your
clone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12310>
_______________________________________

From report at bugs.python.org  Sun Jun 12 01:53:24 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 11 Jun 2011 23:53:24 +0000
Subject: [issue11553] Docs for: import, packages, site.py, .pth files
In-Reply-To: <1300189190.68.0.0305569633639.issue11553@psf.upfronthosting.co.za>
Message-ID: <1307836404.85.0.931756146689.issue11553@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

"Public name" is a term that describes a convention, not anything enforced by the interpreter. Names starting with underscores typically aren't public either (unless documented otherwise), but that has no effect on the ability to retrieve them as attributes. A glossary entry defining the term may be worthwhile (perhaps with a reference to pydoc.visiblename())

Dirs mentioned in .pkg files *should* be added to "the path". It's just that the path in question is pkg.__path__, not sys.path. That could probably be made clearer, but the docs aren't wrong as they stand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11553>
_______________________________________

From report at bugs.python.org  Sun Jun 12 02:09:10 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Jun 2011 00:09:10 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1307837350.5.0.377928137309.issue11610@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Remember the goal here is *not* to completely eliminate the need to test that objects implement an ABC correctly. It's to make it easier to declare the expected interface in a way that helps readers of the ABC definition to figure out what is going on, and to reduce the proliferation of abstract descriptors.

Since we made a deliberate choice not to do signature checks when ABCs were added to the language, there's nothing an ABC can do to stop someone (for example) overriding an abstract method or descriptor "foo" with "foo = 1". That's almost certainly wrong, but it's wrong at a level that ABCs don't care about.

If someone incorrectly overrides a read/write property with a read-only property and there's nothing in their test suite that picks that up, then that's a flaw in the test suite, not a flaw in the ABC itself.

Regarding the naming, @abstractmethod and __isabstractmethod__ are definitely about methods, or method-based descriptors (such as property). There *could* be a case to be made to allow for abstract data attributes, but really, using an abstract property should cover that use case well enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun Jun 12 03:20:59 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Sun, 12 Jun 2011 01:20:59 +0000
Subject: [issue12239] msilib VT_EMPTY SummaryInformation properties raise an
	error (suggest returning None)
In-Reply-To: <1307024024.44.0.716968870376.issue12239@psf.upfronthosting.co.za>
Message-ID: <1307841659.06.0.161133886899.issue12239@psf.upfronthosting.co.za>


Changes by Mark Mc Mahon <mtnbikingmark at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22332/support_vt_empty_in_summary_getproperty.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12239>
_______________________________________

From report at bugs.python.org  Sun Jun 12 03:27:04 2011
From: report at bugs.python.org (Graham Wideman)
Date: Sun, 12 Jun 2011 01:27:04 +0000
Subject: [issue11553] Docs for: import, packages, site.py, .pth files
In-Reply-To: <1300189190.68.0.0305569633639.issue11553@psf.upfronthosting.co.za>
Message-ID: <1307842024.36.0.295579293623.issue11553@psf.upfronthosting.co.za>


Graham Wideman <initcontact at grahamwideman.com> added the comment:

> "Public name" is a term that describes a convention, not anything enforced by the interpreter. 

And I guess that's really the main point. In other languages Public means accessible, and Private means not so.  In Python, Public means "suggested for outside consumption", and Private means not so intended, but nonetheless accessible. If that was reiterated near the discussion of __all__ it would be most helpful.  

>  Dirs mentioned in .pkg files *should* be added to the [...] pkg.__path__, not sys.path. 
> That could probably be made clearer, but the docs aren't wrong as they stand.

Again I've not managed to draw attention to the exact point of contention. 
1. A dir added to a .pkg file evidently should be an actual package dir.  
2. A dir added to a .pth file should NOT be an actual package dir. It should be the dir at the level above.

Thus the entries in .pkg and .pth files point to different kinds of things, yet the doc I pointed to asserts they are the same in this regard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11553>
_______________________________________

From report at bugs.python.org  Sun Jun 12 03:44:36 2011
From: report at bugs.python.org (higery)
Date: Sun, 12 Jun 2011 01:44:36 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1307843076.33.0.233638076934.issue828450@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

OK. I recreated a full version patch. I'll remove old patches.

----------
Added file: http://bugs.python.org/file22333/change_path_separator_fullversion.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Sun Jun 12 03:46:15 2011
From: report at bugs.python.org (higery)
Date: Sun, 12 Jun 2011 01:46:15 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1307843175.27.0.33870971782.issue828450@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Removed 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  Sun Jun 12 03:46:23 2011
From: report at bugs.python.org (higery)
Date: Sun, 12 Jun 2011 01:46:23 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1307843183.87.0.914456795842.issue828450@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Removed file: http://bugs.python.org/file22328/test_manifest_reading_sdist.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Sun Jun 12 03:52:10 2011
From: report at bugs.python.org (Eric Snow)
Date: Sun, 12 Jun 2011 01:52:10 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1307843530.67.0.70584736982.issue11610@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Didn't mean to sidetrack.  :)  I really appreciate the effort Darren has put into this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun Jun 12 03:54:27 2011
From: report at bugs.python.org (higery)
Date: Sun, 12 Jun 2011 01:54:27 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1307815699.9.0.956405486391.issue12279@psf.upfronthosting.co.za>
Message-ID: <BANLkTimr6hokTFOjTq2ue0hYMbehb-aFuA@mail.gmail.com>


higery <shoulderhigher at gmail.com> added the comment:

> Higery: Michael is willing to work with you on this bug.
>

OK.  :)

----------
Added file: http://bugs.python.org/file22334/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________
-------------- next part --------------
<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Higery: Michael is willing to work with you on this bug.<br></blockquote><div><br>OK.?? :)<br></div></div>

From report at bugs.python.org  Sun Jun 12 03:55:58 2011
From: report at bugs.python.org (higery)
Date: Sun, 12 Jun 2011 01:55:58 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1307461733.49.0.987510653631.issue12279@psf.upfronthosting.co.za>
Message-ID: <1307843758.73.0.565098520669.issue12279@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Removed file: http://bugs.python.org/file22334/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Sun Jun 12 05:23:51 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Sun, 12 Jun 2011 03:23: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: <1307849031.15.0.667455678571.issue9035@psf.upfronthosting.co.za>


Mark Mc Mahon <mtnbikingmark at gmail.com> added the comment:

I was looking at this - and see that (at least as far as GetFileAttributes is concerned) that a mount and a linked directory are seen the same...

Here are some tests using ctypes

# mounted drive
>>> hex(windll.kernel32.GetFileAttributesW(ur"c:\temp\test_c_mount"))
'0x410'

# normal directory
>>> hex(windll.kernel32.GetFileAttributesW(ur"c:\temp\orig"))
'0x10'

# link (created via mklink /d c:\temp\orig c:\temp\here2
>>> hex(windll.kernel32.GetFileAttributesW(ur"c:\temp\here2"))
'0x410'

On futher searching - I found the following link:
http://msdn.microsoft.com/en-us/library/aa363940%28v=vs.85%29.aspx

So the function ismount will need to do the following
a) Get the file attributes
b) check that it's a directory and is a reparse point
c) Use FindFirstFile (and FindNextFile? - I need to test more) to fill in WIN32_FIND_DATA.dwResearved0
d) Check that against IO_REPARSE_TAG_MOUNT_POINT (0xA0000003)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9035>
_______________________________________

From report at bugs.python.org  Sun Jun 12 05:25:36 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 12 Jun 2011 03:25:36 +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: <1307849136.79.0.0705973118162.issue9035@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/issue9035>
_______________________________________

From report at bugs.python.org  Sun Jun 12 09:54:06 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Jun 2011 07:54:06 +0000
Subject: [issue11553] Docs for: import, packages, site.py, .pth files
In-Reply-To: <1300189190.68.0.0305569633639.issue11553@psf.upfronthosting.co.za>
Message-ID: <1307865246.98.0.713992597782.issue11553@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah, now I get your point re .pkg vs .pth. I naturally read that as ".pth entries are to sys.path entries as .pkg entries are to pkg.__path__ entries", without any hint that those are the same *kind* of thing. However, I already know that sys.path and pkg.__path__ entries are different, and now I see how it could be misleading for anyone that wasn't as familiar with the distinction.

(This has actually been one of the historic problems with the import documentation - we *don't always know* when something is unclear, because we unconsciously fill in the missing pieces)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11553>
_______________________________________

From report at bugs.python.org  Sun Jun 12 11:02:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Jun 2011 09:02:16 +0000
Subject: [issue12307] Inconsistent formatting of section titles in PEP 0
In-Reply-To: <1307685038.6.0.993227913919.issue12307@psf.upfronthosting.co.za>
Message-ID: <1307869336.35.0.66369096749.issue12307@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

On python.org/dev/peps, I don?t see the extra space that your patch removes.

----------
nosy: +eric.araujo
versions: +3rd party -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12307>
_______________________________________

From report at bugs.python.org  Sun Jun 12 11:05:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Jun 2011 09:05:01 +0000
Subject: [issue12308] Add link to PEP 0 for topical index in wiki
In-Reply-To: <1307685938.0.0.639002265247.issue12308@psf.upfronthosting.co.za>
Message-ID: <1307869501.32.0.997491035625.issue12308@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hm, why not be more ambitious and include your grouping directly in the PEP repository?  You should ask python-dev how they like your wiki page, and then we?ll see if it can be generated from a category or keyword in the PEPs themselves.

P.S. about the version field: this bug is not relevant to the release of 3.3.0.

----------
nosy: +eric.araujo
versions: +3rd party -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12308>
_______________________________________

From report at bugs.python.org  Sun Jun 12 11:06:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Jun 2011 09:06:17 +0000
Subject: [issue10884] pkgutil EggInfoDistribution requirements for .egg-info
	metadata
In-Reply-To: <1294721787.13.0.963133670506.issue10884@psf.upfronthosting.co.za>
Message-ID: <1307869577.92.0.281181390311.issue10884@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> eric.araujo
resolution: works for me -> 
stage:  -> test needed
status: closed -> open
versions: +Python 3.3 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10884>
_______________________________________

From report at bugs.python.org  Sun Jun 12 11:11:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Jun 2011 09:11:00 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1307869860.26.0.251712549564.issue11610@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> there's nothing an ABC can do to stop someone (for example) overriding
> an abstract method or descriptor "foo" with "foo = 1".

I?ve find it useful to use an abstractproperty to specify an attribute that concrete subclasses have to define.  Was that wrong?  From a technical viewpoint, I replaced a method with a data attribute, but from a doc/human viewpoint, replacing a property with a regular attribute did not seem wrong to me.

So, if there are guidelines about ?almost certainly wrong? uses of the ABC machinery, they should IMO be documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun Jun 12 12:04:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Jun 2011 10:04:45 +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: <1307873085.06.0.497920541994.issue10946@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
hgrepos: +27

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10946>
_______________________________________

From report at bugs.python.org  Sun Jun 12 12:05:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Jun 2011 10:05:56 +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: <1307873156.51.0.535397809768.issue10946@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file22335/a099e7001aa8.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10946>
_______________________________________

From report at bugs.python.org  Sun Jun 12 12:07:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Jun 2011 10:07:10 +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: <1307873230.05.0.938743675979.issue10946@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ll edit the patch to use set_undefined_options.

----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10946>
_______________________________________

From report at bugs.python.org  Sun Jun 12 12:47:13 2011
From: report at bugs.python.org (harobed)
Date: Sun, 12 Jun 2011 10:47:13 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
	"chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>


New submission from harobed <stephane at harobed.org>:

Hi,

HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data.

Exemple, I can't do PUT request with chunk transfert.

Regards,
Stephane

----------
components: Library (Lib)
messages: 138203
nosy: harobed
priority: normal
severity: normal
status: open
title: [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12319>
_______________________________________

From report at bugs.python.org  Sun Jun 12 12:55:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Jun 2011 10:55:36 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1307876136.31.0.544296974025.issue828450@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have changed some things in your patch.  There are still two issues:

1) setting os.sep to \ in the tests is not enough to trigger the bug.  This means that the tests really test something only on Windows.  I?ll edit them to mock the OS layer and return paths with \, so that we can check that manifest or sdist does the conversion.

2) I am not sure we can actually change this in distutils, because of the compatibility policy.  The documentation does not say that the MANIFEST file should be portable, so I?ll ask on distutils-sig for feedback.

----------
resolution: accepted -> 
Added file: http://bugs.python.org/file22336/manifest-sep.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Sun Jun 12 13:06:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Jun 2011 11:06:27 +0000
Subject: [issue5243] Missing dependency in distutils build
In-Reply-To: <1234519029.27.0.18013582736.issue5243@psf.upfronthosting.co.za>
Message-ID: <1307876787.71.0.99653959346.issue5243@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> for projects already having a workaround, what will happen?
I think I have the answer to my question: if build_clib is called twice, the registry in Distribution will know that it has run and won?t run it again.  I?ll test manually and if I confirm, I will commit this change.

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5243>
_______________________________________

From report at bugs.python.org  Sun Jun 12 14:02:42 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Jun 2011 12:02:42 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1307880162.31.0.554485244875.issue11610@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

In that paragraph, I was only talking about cases where "foo = 1" *isn't* a valid override (which, I hope you'll agree, it typically won't be).

Your described approach of declaring an abstract property and then overriding it with an ordinary class attribute is part of the answer I gave Eric in pointing out why a separate concept of an abstract attribute isn't really necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun Jun 12 15:54:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Jun 2011 13:54:56 +0000
Subject: [issue12320] test_packaging failures
In-Reply-To: <1307886896.56.0.892165985484.issue12320@psf.upfronthosting.co.za>
Message-ID: <1307886896.56.0.892165985484.issue12320@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The 3.x buildbots are red following the latest commits:

======================================================================
ERROR: test_cfg_to_args (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/packaging/tests/test_util.py", line 499, in test_cfg_to_args
    self.write_file('setup.cfg', SETUP_CFG % opts)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/packaging/tests/support.py", line 163, in write_file
    f.write(content)
UnicodeEncodeError: 'ascii' codec can't encode character '\xc9' in position 114: ordinal not in range(128)

======================================================================
FAIL: test_user_site (packaging.tests.test_command_install_dist.InstallTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/packaging/tests/test_command_install_dist.py", line 93, in test_user_site
    self._test_user_site()
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/packaging/tests/test_command_install_dist.py", line 122, in _test_user_site
    self.assertTrue(os.path.exists(self.user_base))
AssertionError: False is not true

----------
assignee: eric.araujo
components: Library (Lib), Tests
messages: 138207
nosy: eric.araujo, pitrou
priority: critical
severity: normal
stage: needs patch
status: open
title: test_packaging failures
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12320>
_______________________________________

From report at bugs.python.org  Sun Jun 12 18:06:25 2011
From: report at bugs.python.org (Darren Dale)
Date: Sun, 12 Jun 2011 16:06:25 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1307835171.13.0.973771323328.issue11610@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=2h90UNuafN+Tqb_hSGX6k57LSXA@mail.gmail.com>


Darren Dale <dsdale24 at gmail.com> added the comment:

On Sat, Jun 11, 2011 at 7:32 PM, Eric Snow <report at bugs.python.org> wrote:
>
> Eric Snow <ericsnowcurrently at gmail.com> added the comment:
> Per your last message, if a specific descriptor has an abstract setter then the descriptor should be considered abstract. ?If the implementation of that attribute is not a descriptor should it raise a TypeError? ?If it is a descriptor but it does not have a setter, should it likewise fail?

Consider a framework like Enthought's Traits or Riverbank Computing's
dip, where setting the value of a descriptor can result in other
objects being notified of the change. Both Traits and dip are based on
the concept of interfaces, but imagine someone wanted to develop
something similar based on ABCs. In that case, one could argue that
replacing the descriptor with a regular attribute, or another
read-only descriptor, would not satisfy the ABC specification. Then it
might be nice if the abc mechanisms could catch the error. But it
looks like this will be difficult in cases where the subclasses
replaces the descriptor, unless perhaps an AbstractDescriptor were
provided that explained how ABCMeta is going to identify abstract
methods:

    class AbstractDescriptor(metaclass=abc.ABCMeta):
        @property
        @abc.abstractmethod
        def __abstractmethods__(self):
            # it would be nice if descriptors new their own names here,
            # __abstractmethods__ could return: ('bar.fget', 'bar.fset')
            return frozenset(m for m in ('fget', 'fset', 'fdel')
                             if getattr(getattr(self, m, None),
                                        '__isabstractmethod__', False))
        @property
        def __isabstractmethod__(self):
            return True if self.__abstractmethods__

    AbstractDescriptor.register(property)

Of course, not all descriptors would be required to derive from
AbstractDescriptor. There is no intended stick, but the carrot is
better integration with with ABCs.

Having said all that, I think the above suggestion including
__abstractmethods__ for descriptors makes unreasonable demands of
conformity between various descriptor implementations, and that Nick's
suggestion of simply asking descriptors to provide an
__isabstractmethod__ descriptor is probably good enough. Sufficient
documentation of an ABC's interface can cover the rest.

The inspect module or something like it may still be needed in ABCMeta
to work around the general issue Daniel discovered with staticmethod.
That way ABCMeta could inspect the descriptors themselves and attempt
to retrieve their __isabstractmethod__ value.

(aside: unlike ABCMeta.__new__, ABCMeta.register makes no attempt to
verify that the class being registered actually meets the
specification. Why not have ABCMeta.register perform the same checks
as ABCMeta.__new__, and raise an error if the registered class does
not conform to the specification?)

My work is going to keep me pretty busy over the next three weeks, and
I'm still not accomplished with Python's C-API. If someone else wants
to take a crack at the next patch, please feel free.

Darren

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun Jun 12 18:15:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Jun 2011 16:15:34 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1307895334.54.0.230511680554.issue11610@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Non-conformant explicit registration is permitted on purpose to allow developers to only supply partial implementations when it is known that that is all a given application requires. Extremely impure, but quite practical :)

Note that the core logic of inspect.getattr_static isn't all that complicated. If necessary, it could be moved inside the module with ABCMeta and then wrapped or reference by the inspect module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:31:00 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:31:00 +0000
Subject: [issue4841] io's close() not handling errors correctly
In-Reply-To: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za>
Message-ID: <1307903460.74.0.59049169656.issue4841@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4841>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:32:20 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:32:20 +0000
Subject: [issue3665] Support \u and \U escapes in regexes
In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za>
Message-ID: <1307903540.39.0.80608767615.issue3665@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3665>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:33:45 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:33:45 +0000
Subject: [issue5905] strptime fails in non-UTF locale
In-Reply-To: <1241277441.59.0.031362936917.issue5905@psf.upfronthosting.co.za>
Message-ID: <1307903625.9.0.83907877009.issue5905@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Still a problem in 3.2.1 or 3.3?

----------
nosy: +terry.reedy
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5905>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:34:16 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:34:16 +0000
Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol
In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>
Message-ID: <1307903656.58.0.160119742997.issue2175@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2175>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:34:44 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:34:44 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1307903684.45.0.0997011110667.issue8746@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:35:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:35:27 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1307903727.8.0.729556017929.issue2193@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:35:56 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:35:56 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1307903756.41.0.493866378057.issue1692335@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:36:09 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:36:09 +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: <1307903769.26.0.822949562508.issue10037@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10037>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:37:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:37:24 +0000
Subject: [issue5219] IDLE/Tkinter: edit win stops updating when tooltip is
	active
In-Reply-To: <1234382300.54.0.847679485731.issue5219@psf.upfronthosting.co.za>
Message-ID: <1307903844.94.0.665357045358.issue5219@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5219>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:38:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:38:18 +0000
Subject: [issue4653] Patch to fix typos for Py3K
In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za>
Message-ID: <1307903898.23.0.609129027801.issue4653@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4653>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:39:04 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:39:04 +0000
Subject: [issue9246] os.getcwd() hardcodes max path len
In-Reply-To: <1279023059.26.0.245683093399.issue9246@psf.upfronthosting.co.za>
Message-ID: <1307903944.34.0.899556994898.issue9246@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9246>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:40:31 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:40:31 +0000
Subject: [issue2716] Reimplement audioop because of copyright issues
In-Reply-To: <1209428570.75.0.48368829493.issue2716@psf.upfronthosting.co.za>
Message-ID: <1307904031.84.0.733673699384.issue2716@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> needs patch
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2716>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:42:40 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:42:40 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
	directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: <1307904160.35.0.964905829034.issue7732@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:43:39 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:43:39 +0000
Subject: [issue9405] crash when calling urllib.getproxies() under OSX with
	subprocess / particular memory usage
In-Reply-To: <1280352635.35.0.910645426575.issue9405@psf.upfronthosting.co.za>
Message-ID: <1307904219.91.0.37195873947.issue9405@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9405>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:46:08 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:46:08 +0000
Subject: [issue1102] Add support for _msi.Record.GetString() and
	_msi.Record.GetInteger()
In-Reply-To: <1188940010.27.0.383470464739.issue1102@psf.upfronthosting.co.za>
Message-ID: <1307904368.78.0.288631721014.issue1102@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Martin, would this go in a bugfix release or is it a new feature for 3.3 only?

----------
nosy: +terry.reedy
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1102>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:46:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:46:28 +0000
Subject: [issue1207466] installer ignores changed installation directory
Message-ID: <1307904388.72.0.234671292772.issue1207466@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1207466>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:47:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:47:50 +0000
Subject: [issue1469629] __dict__ = self in subclass of dict causes a memory
	leak?
Message-ID: <1307904470.36.0.364273184178.issue1469629@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -BreamoreBoy
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1469629>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:50:10 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:50:10 +0000
Subject: [issue2122] mmap.flush does not check for errors on windows
In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>
Message-ID: <1307904610.9.0.526827473431.issue2122@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2122>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:52:16 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Jun 2011 18:52:16 +0000
Subject: [issue1102] Add support for _msi.Record.GetString() and
	_msi.Record.GetInteger()
In-Reply-To: <1188940010.27.0.383470464739.issue1102@psf.upfronthosting.co.za>
Message-ID: <1307904736.95.0.611284274448.issue1102@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I lost track what problem precisely this patch solves, so it's hard to tell whether it's a bug fix or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1102>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:52:17 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 18:52:17 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated
	AF_UNIX	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1307904737.29.0.168743580812.issue8372@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Is this a security issue or just a regular bug?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Sun Jun 12 20:53:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Jun 2011 18:53:20 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated
	AF_UNIX	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1307904800.54.0.320917795524.issue8372@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's a potential security issue.

----------
nosy: +neologix, rosslagerwall
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Sun Jun 12 21:21:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Jun 2011 19:21:04 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
	directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: <1307906464.87.0.14391778622.issue7732@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Sun Jun 12 21:41:42 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 19:41:42 +0000
Subject: [issue1669539] Fix bug in os.path.join
Message-ID: <1307907702.36.0.776512325897.issue1669539@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

A bug for tracker purposes is a discrepancy between doc and code. That can be fixed in current versions. A design change is a feature request and can only go in future versions. A deprecation warning for one cycle is desirable when appropriate.

"os.path.isabs(path) 
Return True if path is an absolute pathname. On Unix, that means it begins with a slash, on Windows that it begins with a (back)slash after chopping off a potential drive letter."

>From what you report, the code does just that, so there is no bug.
Breaking code just because you do not like the current definition is very unlikely to be accepted.

Adding a .isrelative(path) that seems to be equivalent to 'not .ispath' is unlikely to accepted. People who care about the presence of a drive letter can write "path[1]==':'"

"os.path.join(path1[, path2[, ...]]) 
Join one or more path components intelligently. If any component is an absolute path, all previous components (on Windows, including the previous drive letter, if there was one) are thrown away, and joining continues."

>>> import os
>>> os.path.join('foo', 'a:bar')
'foo\\a:bar'

Producing a non-path does not seem intelligent, so I agree that this a bug. I am not sure what this should produce. 'foo/bar', 'a:foo/bar', and raising an exception would be candidates. All would be better than the current useless return. In any case, a bug fix patch can only fix bugs and should not be intermixed with feature patches.

As to the second sentence: your proposal to change documented and inplemented semantics is, again, a feature request, not a bug fix.

If you want to continue with your feature requests, you can if you wish reclassify this issue, retitle again, and open a new behavior issue for the path bug and upload a bugfix-only patch. Before or along with doing so, I would suggest discussion on the python-ideas list.

----------
nosy: +terry.reedy -BreamoreBoy
title: Change (fix!) os.path.isabs() semantics on Win32 -> Fix bug in os.path.join
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1669539>
_______________________________________

From report at bugs.python.org  Sun Jun 12 21:46:15 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 19:46:15 +0000
Subject: [issue1599254] mailbox: other programs' messages can vanish without
	trace
Message-ID: <1307907975.41.0.545658317836.issue1599254@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

D. Watson, could you remove obsolete patches and leave just the ones a patch reviewer should look at?

----------
nosy: +r.david.murray, terry.reedy -BreamoreBoy
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1599254>
_______________________________________

From report at bugs.python.org  Sun Jun 12 21:54:38 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Sun, 12 Jun 2011 19:54:38 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1307908478.04.0.140076649422.issue8746@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

I apologize for taking so long with this. The attached patch is for test_posix against trunk (I shuffled around some code and extended some things to improve PosixTester.tearDown). Let me know if I need to wash, rinse, repeat for py3k, etc.

Thanks!

# Standard ports copy of python 2.7 without the *chflags configure fix.

$ python2.7 Lib/test/test_posix.py 
testNoArgFunctions (__main__.PosixTester) ... ok
test_access (__main__.PosixTester) ... ok
test_chdir (__main__.PosixTester) ... ok
test_chflags (__main__.PosixTester) ... skipped 'test needs os.chflags()'
test_chown (__main__.PosixTester) ... ok
test_confstr (__main__.PosixTester) ... ok
test_dup (__main__.PosixTester) ... ok
test_dup2 (__main__.PosixTester) ... ok
test_fchown (__main__.PosixTester) ... ok
test_fdopen (__main__.PosixTester) ... ok
test_fstat (__main__.PosixTester) ... ok
test_fstatvfs (__main__.PosixTester) ... ok
test_ftruncate (__main__.PosixTester) ... ok
test_getcwd_long_pathnames (__main__.PosixTester) ... ok
test_getresgid (__main__.PosixTester) ... ok
test_getresuid (__main__.PosixTester) ... ok
test_initgroups (__main__.PosixTester) ... ok
test_lchflags_regular_file (__main__.PosixTester) ... skipped 'test needs os.lchflags()'
test_lchflags_symlink (__main__.PosixTester) ... skipped 'test needs os.lchflags()'
test_lchown (__main__.PosixTester) ... ok
test_lsdir (__main__.PosixTester) ... ok
test_osexlock (__main__.PosixTester) ... ok
test_osshlock (__main__.PosixTester) ... ok
test_pipe (__main__.PosixTester) ... ok
test_setresgid (__main__.PosixTester) ... ok
test_setresgid_exception (__main__.PosixTester) ... ok
test_setresuid (__main__.PosixTester) ... ok
test_setresuid_exception (__main__.PosixTester) ... ok
test_stat (__main__.PosixTester) ... ok
test_statvfs (__main__.PosixTester) ... ok
test_strerror (__main__.PosixTester) ... ok
test_tempnam (__main__.PosixTester) ... ok
test_tmpfile (__main__.PosixTester) ... ok
test_umask (__main__.PosixTester) ... ok
test_utime (__main__.PosixTester) ... ok

----------------------------------------------------------------------
Ran 35 tests in 0.020s

OK (skipped=3)

# Hand compiled version using sources from trunk.

$ /scratch/python/2.7/bin/python Lib/test/test_posix.py 
testNoArgFunctions (__main__.PosixTester) ... ok
test_access (__main__.PosixTester) ... ok
test_chdir (__main__.PosixTester) ... ok
test_chflags (__main__.PosixTester) ... ok
test_chown (__main__.PosixTester) ... ok
test_confstr (__main__.PosixTester) ... ok
test_dup (__main__.PosixTester) ... ok
test_dup2 (__main__.PosixTester) ... ok
test_fchown (__main__.PosixTester) ... ok
test_fdopen (__main__.PosixTester) ... ok
test_fstat (__main__.PosixTester) ... ok
test_fstatvfs (__main__.PosixTester) ... ok
test_ftruncate (__main__.PosixTester) ... ok
test_getcwd_long_pathnames (__main__.PosixTester) ... ok
test_getresgid (__main__.PosixTester) ... ok
test_getresuid (__main__.PosixTester) ... ok
test_initgroups (__main__.PosixTester) ... ok
test_lchflags_regular_file (__main__.PosixTester) ... ok
test_lchflags_symlink (__main__.PosixTester) ... ok
test_lchown (__main__.PosixTester) ... ok
test_lsdir (__main__.PosixTester) ... ok
test_osexlock (__main__.PosixTester) ... ok
test_osshlock (__main__.PosixTester) ... ok
test_pipe (__main__.PosixTester) ... ok
test_setresgid (__main__.PosixTester) ... ok
test_setresgid_exception (__main__.PosixTester) ... ok
test_stat (__main__.PosixTester) ... ok
test_statvfs (__main__.PosixTester) ... ok
test_strerror (__main__.PosixTester) ... ok
test_tempnam (__main__.PosixTester) ... ok
test_tmpfile (__main__.PosixTester) ... ok
test_umask (__main__.PosixTester) ... ok
test_utime (__main__.PosixTester) ... ok

----------------------------------------------------------------------
Ran 35 tests in 0.009s

OK

----------
Added file: http://bugs.python.org/file22337/issue8746-test_posix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sun Jun 12 22:08:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 12 Jun 2011 20:08:42 +0000
Subject: [issue12320] test_packaging failures
In-Reply-To: <1307886896.56.0.892165985484.issue12320@psf.upfronthosting.co.za>
Message-ID: <E1QVqxd-0003in-2b@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9eecfeaa591a by ?ric Araujo in branch 'default':
Specify the encoding of the setup.cfg in one packaging test (#12320)
http://hg.python.org/cpython/rev/9eecfeaa591a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12320>
_______________________________________

From report at bugs.python.org  Sun Jun 12 22:28:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Jun 2011 20:28:14 +0000
Subject: [issue12206] Documentation Std. Library 15.7.5 "LogRecord objects":
	Parameters: level(currently wrong) -> levelno (correct)
In-Reply-To: <1306666020.34.0.114942173152.issue12206@psf.upfronthosting.co.za>
Message-ID: <1307910494.61.0.746113473728.issue12206@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22187/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12206>
_______________________________________

From report at bugs.python.org  Sun Jun 12 22:30:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Jun 2011 20:30:55 +0000
Subject: [issue3665] Support \u and \U escapes in regexes
In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za>
Message-ID: <1307910655.64.0.00880753371814.issue3665@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FYI,
+                raise error("bogus escape: %s" % repr(escape))

can be written simply as

+                raise error("bogus escape: %r" % escape)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3665>
_______________________________________

From report at bugs.python.org  Sun Jun 12 22:36:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Jun 2011 20:36:31 +0000
Subject: [issue4653] Patch to fix typos in C code
In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za>
Message-ID: <1307910991.94.0.221960043759.issue4653@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Martin would be the expert for bdist_wininst.

----------
nosy: +eric.araujo
title: Patch to fix typos for Py3K -> Patch to fix typos in C code

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4653>
_______________________________________

From report at bugs.python.org  Sun Jun 12 23:03:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 12 Jun 2011 21:03:12 +0000
Subject: [issue12320] test_packaging failures
In-Reply-To: <1307886896.56.0.892165985484.issue12320@psf.upfronthosting.co.za>
Message-ID: <E1QVroM-0007Ca-T3@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0e22c47b47a3 by ?ric Araujo in branch 'default':
Also specify encoding when reading setup.cfg (#12320)
http://hg.python.org/cpython/rev/0e22c47b47a3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12320>
_______________________________________

From report at bugs.python.org  Sun Jun 12 23:24:48 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 21:24:48 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated
	AF_UNIX	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1307913888.79.0.215779671691.issue8372@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
type: behavior -> security

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Sun Jun 12 23:29:52 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 21:29:52 +0000
Subject: [issue1598083] Top-level exception handler writes to stdout unsafely
Message-ID: <1307914192.56.0.932250739617.issue1598083@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1598083>
_______________________________________

From report at bugs.python.org  Sun Jun 12 23:30:04 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 21:30:04 +0000
Subject: [issue10340] asyncore doesn't properly handle EINVAL on OSX
In-Reply-To: <1289055392.69.0.485144076522.issue10340@psf.upfronthosting.co.za>
Message-ID: <1307914204.37.0.911563661731.issue10340@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10340>
_______________________________________

From report at bugs.python.org  Sun Jun 12 23:30:31 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 21:30:31 +0000
Subject: [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1307914231.73.0.108168369544.issue6696@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6696>
_______________________________________

From report at bugs.python.org  Sun Jun 12 23:31:40 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 21:31:40 +0000
Subject: [issue4180] warnings.simplefilter("always") does not make warnings
	always show up
In-Reply-To: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za>
Message-ID: <1307914300.92.0.777361628701.issue4180@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4180>
_______________________________________

From report at bugs.python.org  Sun Jun 12 23:35:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 21:35:47 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1307914547.76.0.784790841209.issue5945@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Sun Jun 12 23:37:37 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 21:37:37 +0000
Subject: [issue3006] subprocess.Popen causes socket to remain open after close
In-Reply-To: <1212094958.77.0.0391223554576.issue3006@psf.upfronthosting.co.za>
Message-ID: <1307914657.5.0.0783031202355.issue3006@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3006>
_______________________________________

From report at bugs.python.org  Sun Jun 12 23:39:36 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 21:39:36 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1307914776.87.0.814983571538.issue6697@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Mon Jun 13 00:19:53 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 22:19:53 +0000
Subject: [issue8743] set() operators don't work with collections.Set instances
In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>
Message-ID: <1307917193.45.0.0701239472418.issue8743@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If the code were acting exactly as documented, I would consider this a feature request. But "require that the parameter also be an instance of set()" (from original message) is too limited.

>>> set() | frozenset()
set()

So 'set' in "their operator based counterparts require their arguments to be sets." (doc) seems to be meant to be more generic, in which case 'instance of collections.Set' seems reasonable. To be clear, the doc could be updated to "... sets, frozensets, and other instances of collections.Set."

"Both set and frozenset support set to set comparisons. " This includes comparisons between the two classes.

>>> set() == frozenset()
True

so perhaps comparisons should be extended also.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8743>
_______________________________________

From report at bugs.python.org  Mon Jun 13 00:21:10 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 22:21:10 +0000
Subject: [issue8036] Interpreter crashes on invalid arg to spawnl on Windows
In-Reply-To: <1267477949.48.0.216202239381.issue8036@psf.upfronthosting.co.za>
Message-ID: <1307917270.16.0.675463292274.issue8036@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8036>
_______________________________________

From report at bugs.python.org  Mon Jun 13 00:22:17 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 22:22:17 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1307917337.09.0.865603562041.issue8847@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Mon Jun 13 00:25:17 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 22:25:17 +0000
Subject: [issue1429] FD leak in SocketServer
In-Reply-To: <1194870454.07.0.621713310435.issue1429@psf.upfronthosting.co.za>
Message-ID: <1307917517.53.0.751776262438.issue1429@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1429>
_______________________________________

From report at bugs.python.org  Mon Jun 13 00:25:57 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 22:25: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: <1307917557.1.0.613460876374.issue9614@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9614>
_______________________________________

From report at bugs.python.org  Mon Jun 13 00:35:22 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Jun 2011 22:35:22 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1307918122.33.0.366383700532.issue11205@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If I understand, since the present patch uses present opcode semantics, adding a rotate, it could go into 2.7 and 3.2. Correct?

3.3 could get an improved patch that instead changed opcodes to expect key and value in the other order.

----------
nosy: +terry.reedy
stage:  -> patch review
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Mon Jun 13 00:37:35 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 12 Jun 2011 22:37:35 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated
	AF_UNIX	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1307918255.48.0.510314783448.issue8372@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The patches look good to me, except that instead of passing
(addrlen > buflen) ? buflen : addrlen

as addrlen argument every time makesockaddr is called, I'd prefer if this min was done inside makesockaddr itself, i.e. perform min(addrlen, sizeof(struct sockaddr_un)) in the AF_UNIX switch case (especially since addrlen is only used for AF_UNIX).
Also, this would be the occasion to put a short explanatory comment (possibility of non NULL-terminated sun_path and unreliable length returned by syscalls).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Mon Jun 13 02:03:18 2011
From: report at bugs.python.org (Ameya Lokare)
Date: Mon, 13 Jun 2011 00:03:18 +0000
Subject: [issue7969] shutil.copytree error handling non-standard and partially
	broken
In-Reply-To: <1266617058.24.0.24785922897.issue7969@psf.upfronthosting.co.za>
Message-ID: <1307923398.86.0.982448089706.issue7969@psf.upfronthosting.co.za>


Ameya Lokare <lokare.ameya at gmail.com> added the comment:

shutil.Error is raised in copytree, copyfile and move, with a different format in each case. I was thinking the Error argument format could be documented in the descriptions of these functions (possibly with some examples). What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7969>
_______________________________________

From report at bugs.python.org  Mon Jun 13 02:58:57 2011
From: report at bugs.python.org (Ori Livneh)
Date: Mon, 13 Jun 2011 00:58:57 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1307926737.55.0.628678463878.issue11197@psf.upfronthosting.co.za>


Ori Livneh <ori.livneh at gmail.com> added the comment:

I updated the patch, making the emendations suggested by Eric's review, and making a few additional changes. I was bothered that translate_path was duplicating functionality from _url_collapse_path_split, so I made some corrections to the latter and rewrote translate_path so that it uses _url_collapse_path_split and implements only the checks necessary for translating the path to a path on the local file system path.

translate_path relies on os.path to make sure the path is safe, which is (I think) also the proper way to do things, since it's not good to have to remember to update path semantics in http.server if Python is ported to additional platforms.

I also read the various specs and made sure entities are unquoted at the appropriate point.

----------
Added file: http://bugs.python.org/file22338/translate_path_rev2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11197>
_______________________________________

From report at bugs.python.org  Mon Jun 13 05:00:20 2011
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 13 Jun 2011 03:00:20 +0000
Subject: [issue2122] mmap.flush does not check for errors on windows
In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>
Message-ID: <1307934020.5.0.90557610988.issue2122@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This issue seems to be reproduced in following way.

1. Attach USB flash drive. (On my machine, it was attached as E drive)

2. Run python interactive shell and run following commands.
   (Confirmed on Python2.6)

  > import mmap
  > f = open("e:/temp.tmp", "w+b")
  > f.write("foo")
  > f.flush()
  > m = mmap.mmap(f.fileno(), 3)
  > m[:] = "xxx"

3. Detach USB flash drive violently here! (Without safety mechanism
   to detach USB flash drive, just plug it off) Note that
   python shell is still running.

4. Enter following command in python shell.
  > m.flush()
   It returns *0*. (Means failure)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2122>
_______________________________________

From report at bugs.python.org  Mon Jun 13 11:49:21 2011
From: report at bugs.python.org (patrick vrijlandt)
Date: Mon, 13 Jun 2011 09:49:21 +0000
Subject: [issue12321] documentation of ElementTree.find
In-Reply-To: <1307958561.6.0.547513151308.issue12321@psf.upfronthosting.co.za>
Message-ID: <1307958561.6.0.547513151308.issue12321@psf.upfronthosting.co.za>


New submission from patrick vrijlandt <patrick.vrijlandt at gmail.com>:

>From the python docs for version 3.2:

19.12.3. ElementTree Objects
find(match)
[...] Same as getroot().find(match). [...]

This is not true: tree.find accepts an absolute path (like "/*") , whereas element.find doesn't. Also applies to findall and findtext.

----------
components: XML
messages: 138228
nosy: patrick.vrijlandt
priority: normal
severity: normal
status: open
title: documentation of ElementTree.find
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12321>
_______________________________________

From report at bugs.python.org  Mon Jun 13 12:02:49 2011
From: report at bugs.python.org (patrick vrijlandt)
Date: Mon, 13 Jun 2011 10:02:49 +0000
Subject: [issue12322] ElementPath 1.3 expressions documentation
In-Reply-To: <1307959369.7.0.162667287307.issue12322@psf.upfronthosting.co.za>
Message-ID: <1307959369.7.0.162667287307.issue12322@psf.upfronthosting.co.za>


New submission from patrick vrijlandt <patrick.vrijlandt at gmail.com>:

Python 3.2 supports ElementPath version 1.3. The relevant documentation is
http://effbot.org/zone/element-xpath.htm. It says:
..	(New in 1.3) Selects the parent element.

However, a CHANGES document says:
The engine also provides limited support for the ".." parent operator; you can use it inside the subtree, but it cannot go above the target element (the element you called "find" on).  

The normal documentation should document the limitation.

----------
components: XML
messages: 138229
nosy: patrick.vrijlandt
priority: normal
severity: normal
status: open
title: ElementPath 1.3 expressions documentation
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12322>
_______________________________________

From report at bugs.python.org  Mon Jun 13 12:11:33 2011
From: report at bugs.python.org (patrick vrijlandt)
Date: Mon, 13 Jun 2011 10:11:33 +0000
Subject: [issue12323] ElementPath 1.3 expressions
In-Reply-To: <1307959893.21.0.719611338142.issue12323@psf.upfronthosting.co.za>
Message-ID: <1307959893.21.0.719611338142.issue12323@psf.upfronthosting.co.za>


New submission from patrick vrijlandt <patrick.vrijlandt at gmail.com>:

>From http://effbot.org/zone/element-xpath.htm:

[position]	(New in 1.3) Selects all elements that are located at the given position. The position can be either an integer (1 is the first position), the expression ?last()? (for the last position), or a position relative to last() (e.g. ?last()-1? for the second to last position). This predicate must be preceeded by a tag name.

Testing shows, that [0] is accepted, and seems to be [last()]. 
However [-1] selects no elements. I think these expressions should raise an exception. (Or the feature should be 0-based and behave like python list indices)

----------
components: XML
messages: 138230
nosy: patrick.vrijlandt
priority: normal
severity: normal
status: open
title: ElementPath 1.3 expressions
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12323>
_______________________________________

From report at bugs.python.org  Mon Jun 13 12:18:26 2011
From: report at bugs.python.org (DDarko)
Date: Mon, 13 Jun 2011 10:18:26 +0000
Subject: [issue12324] [3.2] sorted(big dict)
In-Reply-To: <1307960306.32.0.147615969917.issue12324@psf.upfronthosting.co.za>
Message-ID: <1307960306.32.0.147615969917.issue12324@psf.upfronthosting.co.za>


New submission from DDarko <ddarko.dd at gmail.com>:

I added an example to reproduce the bug.
>From the command line the same code:
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) [GCC 4.5.2] on linux2

$ python sort_test.py

Everything fine.

Python 3.2 (r32:88445, Mar 25 2011, 19:28:28) [GCC 4.5.2] on linux2

$ python3 sort_test.py 
Traceback (most recent call last):
  File "sort_test.py", line 1821, in <module>
    r = sorted(d.items(), key=operator.itemgetter(1), reverse=1)
TypeError: unorderable types: dict() < dict()

----------
files: sort_test.py
messages: 138231
nosy: DDarko
priority: normal
severity: normal
status: open
title: [3.2] sorted(big dict)
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22339/sort_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12324>
_______________________________________

From report at bugs.python.org  Mon Jun 13 13:17:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Jun 2011 11:17:41 +0000
Subject: [issue2122] mmap.flush does not check for errors on windows
In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>
Message-ID: <1307963861.9.0.830852503134.issue2122@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/issue2122>
_______________________________________

From report at bugs.python.org  Mon Jun 13 13:33:33 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 13 Jun 2011 11:33:33 +0000
Subject: [issue12324] [3.2] sorted(big dict)
In-Reply-To: <1307960306.32.0.147615969917.issue12324@psf.upfronthosting.co.za>
Message-ID: <1307964813.59.0.696964121762.issue12324@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is expected behaviour:  Python 3 changed the semantics of the comparison operators <, <=, >, >=.  See:

http://docs.python.org/py3k/whatsnew/3.0.html#ordering-comparisons

for more.

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12324>
_______________________________________

From report at bugs.python.org  Mon Jun 13 14:12:23 2011
From: report at bugs.python.org (DDarko)
Date: Mon, 13 Jun 2011 12:12:23 +0000
Subject: [issue12324] [3.2] sorted(big dict)
In-Reply-To: <1307960306.32.0.147615969917.issue12324@psf.upfronthosting.co.za>
Message-ID: <1307967143.77.0.928720825718.issue12324@psf.upfronthosting.co.za>


DDarko <ddarko.dd at gmail.com> added the comment:

I am aware of this change.
In this example, I'm sort by item number 1, which is a list, and its first value is an int.

$ python3 sort_test.py 
<class 'list'>
<class 'list'>
<class 'list'>
<class 'list'>
<class 'list'>
<class 'list'>
...

Dict index is always No. 2. But I do not sort it.
That's why it surprised me this error because nowhere dicts should not be compared.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12324>
_______________________________________

From report at bugs.python.org  Mon Jun 13 14:24:51 2011
From: report at bugs.python.org (Cal Leeming)
Date: Mon, 13 Jun 2011 12:24:51 +0000
Subject: [issue12325] regex matches incorrectly on literal dot (99.9%
	confirmed)
In-Reply-To: <1307967891.59.0.313731178226.issue12325@psf.upfronthosting.co.za>
Message-ID: <1307967891.59.0.313731178226.issue12325@psf.upfronthosting.co.za>


New submission from Cal Leeming <cal.leeming at simplicitymedialtd.co.uk>:

I believe I might have found a bug in the Python re libraries. Here is a complete debug of what is happening (my apologies for the nature of the actual text). I have ran this regex through RegexBuddy (and a few other tools), and all of them do the correct action (which is to not do any replacement), apart from Python. I haven't yet tried this in another language.

------------ ORIGINAL TEXT ------------
>>313229176 
me and a buddy and his girlfriend were watching tv once and this blabbering idiot starts talking about this scientific study she heard about where they built a fake city and only one guy didn't know that it was a fake. we all paused for a second and i said "the truman show?" and she says "yeah! that was the name of it!" me my buddy and his girlfriend all catch eyes and are baffled at how stupid she was
----------------------------------------

------------ TEXT AFTER REGEX SUB ------------

me and a buddy and his girlfriend were http://watching.tv once and this blabbering idiot starts talking about this scientific study she heard about where they built a fake city and only one guy didn't know that it was a fake.we all paused for a second and i said "the truman show?" and she says "yeah! that was the name of it!" me my buddy and his girlfriend all catch eyes and are baffled at how stupid she was
-----------------------------------------------

----------- REPLACED TEXT -----------
 watching tv 
 http://watching.tv 
-----------------------------------------------


---- REGEX ----
_t = re.compile(r"(^| )((?:[\w\-]{2,}?\.|)(?:[\w\-]{2,}?)(?:\.com|\.net|\.org|\.co\.uk|\.tv|\.ly))", flags = re.IGNORECASE | re.MULTILINE | re.DEBUG)

---- COMMAND ----
_t.sub("\\1http://\\2", original_message_here)


---- REGEX DEBUG ----

subpattern 1
  branch
    at at_beginning
  or
    literal 32
subpattern 2
  subpattern None
    branch
      min_repeat 2 65535
        in
          category category_word
          literal 45
      literal 46
    or
  subpattern None
    min_repeat 2 65535
      in
        category category_word
        literal 45
  subpattern None
    literal 46
    branch
      literal 99
      literal 111
      literal 109
    or
      literal 110
      literal 101
      literal 116
    or
      literal 111
      literal 114
      literal 103
    or
      literal 99
      literal 111
      literal 46
      literal 117
      literal 107
    or
      literal 116
      literal 118
    or
      literal 108
      literal 121

----------
components: Regular Expressions
messages: 138234
nosy: Cal.Leeming
priority: normal
severity: normal
status: open
title: regex matches incorrectly on literal dot (99.9% confirmed)
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12325>
_______________________________________

From report at bugs.python.org  Mon Jun 13 14:25:10 2011
From: report at bugs.python.org (Cal Leeming)
Date: Mon, 13 Jun 2011 12:25:10 +0000
Subject: [issue12325] regex matches incorrectly on literal dot (99.9%
	confirmed)
In-Reply-To: <1307967891.59.0.313731178226.issue12325@psf.upfronthosting.co.za>
Message-ID: <1307967910.22.0.516738699857.issue12325@psf.upfronthosting.co.za>


Changes by Cal Leeming <cal.leeming at simplicitymedialtd.co.uk>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12325>
_______________________________________

From report at bugs.python.org  Mon Jun 13 14:29:10 2011
From: report at bugs.python.org (Torsten Bronger)
Date: Mon, 13 Jun 2011 12:29:10 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1307968150.16.0.149792002469.issue4470@psf.upfronthosting.co.za>


Torsten Bronger <bronger at physik.rwth-aachen.de> added the comment:

I still have to apply Catucci's patch (or a modification of) after every Ubuntu installation or upgrade.  Otherwise, I get

  ...
  File "/usr/lib/python2.7/smtplib.py", line 752, in __init__
    SMTP.__init__(self, host, port, local_hostname, timeout)
  File "/usr/lib/python2.7/smtplib.py", line 239, in __init__
    (code, msg) = self.connect(host, port)
  File "/usr/lib/python2.7/smtplib.py", line 295, in connect
    self.sock = self._get_socket(host, port, self.timeout)
  File "/usr/lib/python2.7/smtplib.py", line 757, in _get_socket
    new_socket = socket.create_connection((host, port), timeout)
  File "/usr/lib/python2.7/socket.py", line 571, in create_connection
    raise err
socket.error: [Errno 111] Connection refused

But isn't it that #4066 should have solved the critical part this issue pair 4066/4470?

----------
nosy: +bronger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Mon Jun 13 14:30:52 2011
From: report at bugs.python.org (Cal Leeming)
Date: Mon, 13 Jun 2011 12:30:52 +0000
Subject: [issue12325] regex matches incorrectly on literal dot (99.9%
	confirmed)
In-Reply-To: <1307967891.59.0.313731178226.issue12325@psf.upfronthosting.co.za>
Message-ID: <1307968252.79.0.289507006189.issue12325@psf.upfronthosting.co.za>


Cal Leeming <cal.leeming at simplicitymedialtd.co.uk> added the comment:

Take particular notice to the following:

\.co\.uk

    or
      literal 99
      literal 111
      literal 46
      literal 117
      literal 107


>>> map(lambda x: chr(x), [99,111,46,117,107])
['c', 'o', '.', 'u', 'k']

It would appear it is ignoring the first \. 

But why??

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12325>
_______________________________________

From report at bugs.python.org  Mon Jun 13 14:36:52 2011
From: report at bugs.python.org (DDarko)
Date: Mon, 13 Jun 2011 12:36:52 +0000
Subject: [issue12324] [3.2] sorted(big dict)
In-Reply-To: <1307960306.32.0.147615969917.issue12324@psf.upfronthosting.co.za>
Message-ID: <1307968612.63.0.569105258962.issue12324@psf.upfronthosting.co.za>


DDarko <ddarko.dd at gmail.com> added the comment:

Sure. I know what's going on.
Sorry for the inconvenience.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12324>
_______________________________________

From report at bugs.python.org  Mon Jun 13 14:42:12 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 13 Jun 2011 12:42:12 +0000
Subject: [issue12324] [3.2] sorted(big dict)
In-Reply-To: <1307960306.32.0.147615969917.issue12324@psf.upfronthosting.co.za>
Message-ID: <1307968932.29.0.27141670551.issue12324@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> In this example, I'm sort by item number 1, which is a list, and its
> first value is an int.

?  You're sorting by the values of the dict d, and those values have the form [int, int, dict];  so when the two ints match (e.g., in your data, there are two values of the form [64, 124, {...}]) there's a dictionary comparison.

Did you mean to do:

    sorted(d.values(), key=operator.itemgetter(1), reverse=1)

?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12324>
_______________________________________

From report at bugs.python.org  Mon Jun 13 14:42:59 2011
From: report at bugs.python.org (Robert Lehmann)
Date: Mon, 13 Jun 2011 12:42:59 +0000
Subject: [issue12325] regex matches incorrectly on literal dot (99.9%
	confirmed)
In-Reply-To: <1307967891.59.0.313731178226.issue12325@psf.upfronthosting.co.za>
Message-ID: <1307968979.79.0.562863407116.issue12325@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

I can not reproduce either of your findings.  Could you provide us with your version information?  re version 2.2.1, _sre 2.2.2, Python 2.6.6, Debian sid here.  Also tested with Python 2.7.2rc1 (same RE).

>>> import re
>>> re.compile(r"\.co\.uk", re.DEBUG)
literal 46
literal 99
literal 111
literal 46
literal 117
literal 107
<_sre.SRE_Pattern object at 0xb73b0860>
>>> re.compile(r"(^| )((?:[\w\-]{2,}?\.|)(?:[\w\-]{2,}?)(?:\.com|\.net|\.org|\.co\.uk|\.tv|\.ly))", flags = re.IGNORECASE | re.MULTILINE | re.DEBUG).sub("\\1http://\\2", """me and a buddy and his girlfriend were watching tv once and this blabbering idiot starts talking about this scientific study she heard about where they built a fake city and only one guy didn't know that it was a fake. we all paused for a second and i said "the truman show?" and she says "yeah! that was the name of it!" me my buddy and his girlfriend all catch eyes and are baffled at how stupid she was""")
subpattern 1
...
'me and a buddy and his girlfriend were watching tv once...'

----------
nosy: +lehmannro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12325>
_______________________________________

From report at bugs.python.org  Mon Jun 13 14:53:45 2011
From: report at bugs.python.org (Cal Leeming)
Date: Mon, 13 Jun 2011 12:53:45 +0000
Subject: [issue12325] regex matches incorrectly on literal dot (99.9%
	confirmed)
In-Reply-To: <1307967891.59.0.313731178226.issue12325@psf.upfronthosting.co.za>
Message-ID: <1307969625.11.0.593409126118.issue12325@psf.upfronthosting.co.za>


Cal Leeming <cal.leeming at simplicitymedialtd.co.uk> added the comment:

Oh jeez, you're going to think I'm such an idiot. I just ran a completely fresh test in the cli (away from the original source), and the issue disappeared (it was caused by caching - apparently).

I'm really sorry to have bothered you guys, I should have thought and tested this outside the original code first. I'll make sure to do this before posting any bugs in the future.

Thank you for your extremely fast response though!

Cal

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12325>
_______________________________________

From report at bugs.python.org  Mon Jun 13 14:56:53 2011
From: report at bugs.python.org (DDarko)
Date: Mon, 13 Jun 2011 12:56:53 +0000
Subject: [issue12324] [3.2] sorted(big dict)
In-Reply-To: <1307960306.32.0.147615969917.issue12324@psf.upfronthosting.co.za>
Message-ID: <1307969813.28.0.858443355785.issue12324@psf.upfronthosting.co.za>


DDarko <ddarko.dd at gmail.com> added the comment:

I am interested in sorting only by INT0, in this example:
{k: [INT0, INT1, DICT], k: [INT0, INT1, DICT], ...}
not cmp. whole lists.

Unfortunately I can not take advantage of .values() as the keys I need.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12324>
_______________________________________

From report at bugs.python.org  Mon Jun 13 14:58:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Jun 2011 12:58:24 +0000
Subject: [issue12323] ElementPath 1.3 expressions
In-Reply-To: <1307959893.21.0.719611338142.issue12323@psf.upfronthosting.co.za>
Message-ID: <1307969904.83.0.713485584953.issue12323@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12323>
_______________________________________

From report at bugs.python.org  Mon Jun 13 14:58:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Jun 2011 12:58:34 +0000
Subject: [issue12322] ElementPath 1.3 expressions documentation
In-Reply-To: <1307959369.7.0.162667287307.issue12322@psf.upfronthosting.co.za>
Message-ID: <1307969914.84.0.992967942306.issue12322@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12322>
_______________________________________

From report at bugs.python.org  Mon Jun 13 14:59:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Jun 2011 12:59:21 +0000
Subject: [issue12321] documentation of ElementTree.find
In-Reply-To: <1307958561.6.0.547513151308.issue12321@psf.upfronthosting.co.za>
Message-ID: <1307969961.48.0.26074218582.issue12321@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12321>
_______________________________________

From report at bugs.python.org  Mon Jun 13 15:01:35 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 13 Jun 2011 13:01:35 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
	"chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1307970095.99.0.316380746606.issue12319@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

What's the use case? Do you have an iterable that yields data whose size is unknown?

AFAIK, most web servers don't even support chunked uploads.

(Removing Python 2.7 from versions as this is clearly a feature request.)

----------
nosy: +petri.lehtinen
type:  -> feature request
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12319>
_______________________________________

From report at bugs.python.org  Mon Jun 13 15:14:57 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 13 Jun 2011 13:14:57 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1307970897.1.0.802097753063.issue12181@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> If there are only two versions of the structure on all operating
> systems, we can add a check in configure

Isn't it a bit overkill?
OpenBSD is the only OS to define struct kevent that way, adding a 
#ifdef __OpenBSD__

check would probably be enough, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Mon Jun 13 15:19:08 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 13 Jun 2011 13:19:08 +0000
Subject: [issue12294] multiprocessing.Pool: Need a way to find out if work are
	finished.
In-Reply-To: <1307627992.49.0.467043384727.issue12294@psf.upfronthosting.co.za>
Message-ID: <1307971148.41.0.675599833002.issue12294@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12294>
_______________________________________

From report at bugs.python.org  Mon Jun 13 15:52:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jun 2011 13:52:56 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1307973176.03.0.353214642985.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 3:
 - add unit tests for code pages 932, 1252, CP_UTF7 and CP_UTF8
 - fix encode/decode flags for CP_UTF7/CP_UTF8
 - fix encode name on UnicodeDecodeError, support also "CP_UTF7" and "CP_UTF8" code page names

TODO:

 - The decoder (with errors) doesn't support multibyte characters, e.g. b"\xC3\xA9\xFF" is not correctly decoded using "replace" (insize is fixed to 1)
 - The encoder doesn't support surrogate pairs, but the result with UTF-8 looks correct
 - UTF-7 decoder is not strict, e.g. b'[+/]' is decoded to '[]' in strict mode
 - UTF-8 encoder is not strict, e.g. replace surrogates by U+FFFD
 - Use final in decode_mbcs_errors(): a multibyte character may be splitted between two chunks of INT_MAX bytes
 - Implement suggested Martin's optimizations?

----------
Added file: http://bugs.python.org/file22340/mbcs3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Mon Jun 13 15:56:25 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 13 Jun 2011 13:56:25 +0000
Subject: [issue11728] mbox parser incorrect behaviour
In-Reply-To: <1301573066.6.0.277247050127.issue11728@psf.upfronthosting.co.za>
Message-ID: <1307973385.02.0.3665715882.issue11728@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Hello Valery Masiutsin, i recently stumbled over this while searching
for the link to the standart i've stored in another issue.
(Without being logged in, say.)
The de-facto standart (http://qmail.org/man/man5/mbox.html) says:

HOW A MESSAGE IS READ
          A reader scans through an mbox file looking for From_ lines.
          Any From_ line marks the beginning of a message.  The reader
          should not attempt to take advantage of the fact that every
          From_ line (past the beginning of the file) is preceded by a
          blank line.

This is however the recent version.  The "mbox" manpage of my up-to-date
Mac OS X 10.6.7 does not state this, for example.  It's from 2002.
However, all known MBOX standarts, i.e. MBOXO, MBOXRD, MBOXCL, require
proper quoting of non-From_ "From " lines (by preceeding with '>').
So your example should not fail in Python.
(But hey - are you sure *that* has been produced by Perl?)

You're right however that Python seems to only support the old MBOXO
way of un-escaping only plain "From " to/from ">From ", which is not
even mentioned anymore in the current standart - that only describes
MBOXRD ("(>*From )" -> ">"+match.group(1)). 
(Lucky me: i own Mac OS X, otherwise i wouldn't even know.)
Thus you're in trouble if the unescaping is performed before the split..
This is another issue, though: "MBOX parser uses MBOXO algorithm".

;> - Ciao, Steffen

----------
nosy: +sdaoden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11728>
_______________________________________

From report at bugs.python.org  Mon Jun 13 15:59:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jun 2011 13:59:22 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1307973562.48.0.749485872329.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Using my patch, it is possible create a codec for any code page on demand: register a function checking if the encoding name starts with "cp" and ends with a valid code page number.

Even if it is bad idea to set the OEM code page to 65001, implement a codec for this code page would solve issue #6058 (and help issues #7441 and #10920). See also issue #1602 (Unicode support of the Windows console).

I don't know if the Windows codec should be use, it available, instead of Python builtin codecs for Windows code pages (e.g. "cp1252" encoding).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Mon Jun 13 16:00:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 13 Jun 2011 14:00:44 +0000
Subject: [issue12206] Documentation Std. Library 15.7.5 "LogRecord objects":
	Parameters: level(currently wrong) -> levelno (correct)
In-Reply-To: <1306666020.34.0.114942173152.issue12206@psf.upfronthosting.co.za>
Message-ID: <E1QW7h5-00031V-AN@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5fbf0d010276 by Vinay Sajip in branch '2.7':
Closes #12206: documentation update for LogRecord constructor and Formatter.formatTime.
http://hg.python.org/cpython/rev/5fbf0d010276

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12206>
_______________________________________

From report at bugs.python.org  Mon Jun 13 16:01:17 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 13 Jun 2011 14:01:17 +0000
Subject: [issue12316] test_signal: test_sigwait_thread failure on FreeBSD 6.4
	buildbot
In-Reply-To: <1307745366.26.0.591254125335.issue12316@psf.upfronthosting.co.za>
Message-ID: <BANLkTikNNROP6B-T5Xazi5umM_hgKEinJQ@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

Patch attached:
- a new process is spawned (using assert_python_ok()) to avoid
undefined behavior (and crash on FreeBSD)
- I've kept SIGUSR1 default handler, because, as noted in
http://bugs.python.org/issue8407#msg138066 , there can be subtle
differences between default handlers and user-installed ones which can
mask bugs
- I've fixed a comment in test_sigwait

----------
keywords: +patch
Added file: http://bugs.python.org/file22341/test_sigwait_thread.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12316>
_______________________________________
-------------- next part --------------
diff -r 0e22c47b47a3 Lib/test/test_signal.py
--- a/Lib/test/test_signal.py	Sun Jun 12 23:02:57 2011 +0200
+++ b/Lib/test/test_signal.py	Mon Jun 13 15:53:57 2011 +0200
@@ -9,6 +9,7 @@
 import subprocess
 import traceback
 import sys, os, time, errno
+from test.script_helper import assert_python_ok
 try:
     import threading
 except ImportError:
@@ -627,8 +628,7 @@
             else:
                 os._exit(0)
         else:
-            # parent: let the child some time to wait, send him the signal, and
-            # check it correcty received it
+            # parent: check that the child correcty received the signal
             self.assertEqual(os.waitpid(pid, 0), (pid, 0))
 
     @unittest.skipUnless(hasattr(signal, 'sigwait'),
@@ -649,24 +649,36 @@
     @unittest.skipUnless(hasattr(signal, 'sigwait'),
                          'need signal.sigwait()')
     @unittest.skipIf(threading is None, "test needs threading module")
-    @unittest.skipUnless(hasattr(os, 'fork'), 'need os.fork()')
     def test_sigwait_thread(self):
-        def kill_later(signum):
-            # wait until the main thread is waiting in sigwait()
-            time.sleep(1)
-            os.kill(os.getpid(), signum)
+        # Check that calling sigwait() from a thread doesn't suspend the whole
+        # process.
+        # A new interpreter is spawned to avoid problems when mixing threads and
+        # fork() (only async-safe functions are allowed between fork() and
+        # exec()).
+        assert_python_ok("-c", """if True:
+            import os, threading, sys, time, signal
 
-        def test(signum):
-            killer = threading.Thread(target=kill_later, args=(signum,))
+            # the default handler terminates the process
+            signum = signal.SIGUSR1
+
+            def kill_later():
+                # wait until the main thread is waiting in sigwait()
+                time.sleep(1)
+                os.kill(os.getpid(), signum)
+
+            # the signal must be blocked by all the threads
+            signal.pthread_sigmask(signal.SIG_BLOCK, [signum])
+            killer = threading.Thread(target=kill_later)
             killer.start()
             received = signal.sigwait([signum])
             if received != signum:
                 print("sigwait() received %s, not %s" % (received, signum),
                       file=sys.stderr)
-                os._exit(1)
+                sys.exit(1)
             killer.join()
-
-        self.check_sigwait(test, signal.SIGUSR1)
+            # unblock the signal, which should have been cleared by sigwait()
+            signal.pthread_sigmask(signal.SIG_UNBLOCK, [signum])
+            """)
 
     @unittest.skipUnless(hasattr(signal, 'pthread_sigmask'),
                          'need signal.pthread_sigmask()')

From report at bugs.python.org  Mon Jun 13 16:20:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 13 Jun 2011 14:20:16 +0000
Subject: [issue12316] test_signal: test_sigwait_thread failure on FreeBSD 6.4
	buildbot
In-Reply-To: <1307743284.62.0.757542886858.issue12316@psf.upfronthosting.co.za>
Message-ID: <E1QW7zz-0004pD-96@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d07d0afea9a7 by Victor Stinner in branch 'default':
Issue #12316: Fix sigwait() test using threads
http://hg.python.org/cpython/rev/d07d0afea9a7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12316>
_______________________________________

From report at bugs.python.org  Mon Jun 13 16:23:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jun 2011 14:23:00 +0000
Subject: [issue12316] test_signal: test_sigwait_thread failure on FreeBSD 6.4
	buildbot
In-Reply-To: <1307743284.62.0.757542886858.issue12316@psf.upfronthosting.co.za>
Message-ID: <1307974980.32.0.195324058064.issue12316@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Patch attached

The patch looks correct, but only FreeBSD 6.4 can tell us if it "works" or not, so I commited your new version of the test.

I inlined check_sigwait() because the function was only called by test_sigwait().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12316>
_______________________________________

From report at bugs.python.org  Mon Jun 13 16:32:57 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jun 2011 14:32:57 +0000
Subject: [issue12325] regex matches incorrectly on literal dot (99.9%
	confirmed)
In-Reply-To: <1307967891.59.0.313731178226.issue12325@psf.upfronthosting.co.za>
Message-ID: <1307975577.72.0.731707134307.issue12325@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12325>
_______________________________________

From report at bugs.python.org  Mon Jun 13 16:34:42 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 13 Jun 2011 14:34:42 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

Linus recently decided that the next Linux kernel version would 3.0 [1].
As a consequence, sys.platform (which is actually MACHDEP) will be 'linux3' on machines running Linux 3 kernels, and tests checking explicitely against 'linux2' will either break and won't run.
A quick grep through the code base returns only a couple problematic places, but this should definitely be fixed.
For information, here's a - probably incomplete - list of such occurrences:

"""
./Lib/test/test_logging.py:        if sys.platform in ('linux2', 'darwin'):
./Lib/test/test_sysconfig.py:        sys.platform = 'linux2'
./Lib/test/regrtest.py:    'linux2':
./Lib/test/test_socket.py:    if sys.platform == 'linux2':
./Lib/test/test_tarfile.py:        if sys.platform == "linux2":
./Lib/distutils/tests/test_bdist_rpm.py:        if sys.platform != 'linux2':
./Lib/distutils/tests/test_bdist_rpm.py:        if sys.platform != 'linux2':
./Lib/distutils/tests/test_util.py:        sys.platform = 'linux2'
./Lib/packaging/tests/test_config.py:  inotify (0.0.1); sys.platform == 'linux2'
./Lib/packaging/tests/test_config.py:                  "inotify (0.0.1); sys.platform == 'linux2'"]
./setup.py:        if (platform in ('linux2', 'freebsd4', 'freebsd5', 'freebsd6',
"""

[1] http://thread.gmane.org/gmane.linux.kernel/1147415

----------
messages: 138251
nosy: neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: Linux 3: tests should avoid using sys.platform == 'linux2'
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Jun 13 16:38:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jun 2011 14:38:24 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1307975904.51.0.369737860423.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Why should be used instead?
 - sys.platform.startswith('linux')
 - os.uname()[0] == 'Linux'
 - platform.system() == 'Linux'
 - other?

Tests like sys.platform in ('linux2', 'darwin') can be replaced by sys.platform in ('linux2', 'linux3', 'darwin'). We will have to patch this test again for Linux 4.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Jun 13 16:42:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Jun 2011 14:42:30 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1307976150.1.0.848249522325.issue12326@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I would expect changing sys.platform will also break a lot of third-party code. Perhaps sys.platform can still be 'linux2' under Linux 3.x? After all, there's no significant change that deserves changing sys.platform.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Jun 13 16:50:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jun 2011 14:50:08 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1307976608.63.0.104925996769.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

sys.platform comes from Py_GetPlatform() which comes from PLATFORM define. On Linux, this define comes from Makefile: MACHDEP variable which comes from configure. Finally, MACHDEP is defined by:

	ac_sys_system=`uname -s`
	if test "$ac_sys_system" = "AIX" \
	-o "$ac_sys_system" = "UnixWare" -o "$ac_sys_system" = "OpenUNIX"; then
		ac_sys_release=`uname -v`
	else
		ac_sys_release=`uname -r`
	fi
	ac_md_system=`echo $ac_sys_system |
			   tr -d '/ ' | tr '[A-Z]' '[a-z]'`
	ac_md_release=`echo $ac_sys_release |
			   tr -d '/ ' | sed 's/^[A-Z]\.//' | sed 's/\..*//'`
	MACHDEP="$ac_md_system$ac_md_release"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Jun 13 16:51:12 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 13 Jun 2011 14:51:12 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1307976672.69.0.300868758392.issue12326@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I would expect changing sys.platform will also break a lot of third-
> party code.

Maybe, but this would be an application bug.

Here's sys.platform current implementation:

const char *
Py_GetPlatform(void)
{
    return PLATFORM;
}


And here's the documentation, from http://docs.python.org/c-api/init.html

"""
Return the platform identifier for the current platform. On Unix, this is formed from the ?official? name of the operating system, converted to lower case, followed by the major revision number"""

So it's actually documented.

> Perhaps sys.platform can still be 'linux2' under Linux 3.x? After
> all, there's no significant change that deserves changing
> sys.platform.

Sounds like a recipe for confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Jun 13 16:53:24 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 13 Jun 2011 14:53:24 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1307976804.6.0.415996869285.issue12326@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
nosy: +lemburg, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Jun 13 17:04:55 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 13 Jun 2011 15:04:55 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1307977495.29.0.184287723015.issue12326@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/issue12326>
_______________________________________

From report at bugs.python.org  Mon Jun 13 17:18:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jun 2011 15:18:10 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1307978290.01.0.368037309096.issue12084@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

issue12084_v2.diff doesn't patch os.lstat(bytes): os.lstat(bytes) should call win32_lstat() (which is removed by this patch) instead of stat().

test_os doesn't test os.stat()/os.lstat() with byte filenames. You can for example replace Win32SymlinkTests.check_stat() method by:

    def check_stat(self, link, target):
        self.assertEqual(os.stat(link), os.stat(target))
        self.assertNotEqual(os.lstat(link), os.stat(link))

        bytes_link = os.fsencode(link)
        self.assertEqual(os.stat(bytes_link), os.stat(target))
        self.assertNotEqual(os.lstat(bytes_link), os.stat(bytes_link))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Mon Jun 13 17:30:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jun 2011 15:30:46 +0000
Subject: [issue12316] test_signal: test_sigwait_thread failure on FreeBSD 6.4
	buildbot
In-Reply-To: <1307743284.62.0.757542886858.issue12316@psf.upfronthosting.co.za>
Message-ID: <1307979046.91.0.463830042809.issue12316@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_signal passed in build #1577 of x86 FreeBSD 6.4 3.x: I close this issue. Thanks neologix!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12316>
_______________________________________

From report at bugs.python.org  Mon Jun 13 17:35:20 2011
From: report at bugs.python.org (harobed)
Date: Mon, 13 Jun 2011 15:35:20 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
	"chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1307979320.96.0.507178935106.issue12319@psf.upfronthosting.co.za>


harobed <stephane at harobed.org> added the comment:

I use http.client in WebDAV client.

Mac OS X Finder WebDAV client perform all his request in "chunk" mode : PUT and GET.

Here, I use http.client to simulate Mac OS X Finder WebDAV?client.

Regards,
Stephane

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12319>
_______________________________________

From report at bugs.python.org  Mon Jun 13 17:37:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jun 2011 15:37:46 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1307979466.17.0.906290482113.issue12084@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> os.lstat(bytes) should call win32_lstat()
> (which is removed by this patch) instead of stat()

Short history:
- 0a1baa619171: Fix #10027. st_nlink not set on Windows calls to os.stat/lstat
- 730b728e5aef: Implement #1578269. Patch by Jason R. Coombs.

730b728e5aef adds win32_lstat(), but it doesn't patch posix_lstat(). So your patch is not a regression, it's just that it was never supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Mon Jun 13 18:16:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jun 2011 16:16:01 +0000
Subject: [issue12174] Multiprocessing logging levels unclear
In-Reply-To: <1306324447.9.0.976036464224.issue12174@psf.upfronthosting.co.za>
Message-ID: <1307981761.94.0.188152814616.issue12174@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think it would be good to mention the numeric levels in the text as well (in parenthesis, perhaps), unless the rest of the logging docs no longer refer to the numeric levels.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12174>
_______________________________________

From report at bugs.python.org  Mon Jun 13 18:18:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jun 2011 16:18:47 +0000
Subject: [issue12063] tokenize module appears to treat unterminated single and
	double-quoted strings inconsistently
In-Reply-To: <1305209970.17.0.31373709531.issue12063@psf.upfronthosting.co.za>
Message-ID: <1307981927.08.0.396286738287.issue12063@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree with Petri, so I'm setting this to a doc issue.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12063>
_______________________________________

From report at bugs.python.org  Mon Jun 13 18:27:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jun 2011 16:27:16 +0000
Subject: [issue11669] Clarify Lang Ref "Compound statements" footnote
In-Reply-To: <1301042574.67.0.975748752077.issue11669@psf.upfronthosting.co.za>
Message-ID: <1307982436.51.0.894064377653.issue11669@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Sometimes we use the patch keyword for doc issues where someone has suggested a specific new wording but not generated an actual patch.  That seems to be the case here.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11669>
_______________________________________

From report at bugs.python.org  Mon Jun 13 18:28:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jun 2011 16:28:07 +0000
Subject: [issue11669] Clarify Lang Ref "Compound statements" footnote
In-Reply-To: <1301042574.67.0.975748752077.issue11669@psf.upfronthosting.co.za>
Message-ID: <1307982487.56.0.434263572272.issue11669@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11669>
_______________________________________

From report at bugs.python.org  Mon Jun 13 18:41:06 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 13 Jun 2011 16:41:06 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1307983266.82.0.770300482221.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Here's a cleaned up patch which includes the test and lstat change Victor mentioned. I think this addresses everything we need to cover here. Can you run the tests once more with this new patch?

----------
Added file: http://bugs.python.org/file22342/issue12084_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Mon Jun 13 19:50:09 2011
From: report at bugs.python.org (harobed)
Date: Mon, 13 Jun 2011 17:50:09 +0000
Subject: [issue12327] in HTTPConnection the are len(body) and TypeError catch
	exception to detect if body is file like object,
	this hack do work with StringIO object
In-Reply-To: <1307987409.37.0.379147237937.issue12327@psf.upfronthosting.co.za>
Message-ID: <1307987409.37.0.379147237937.issue12327@psf.upfronthosting.co.za>


New submission from harobed <stephane at harobed.org>:

Hi,

in httplib.HTTPConnection._send_request (Python 2.6)
in httplib.HTTPConnection._set_content_length (Python 2.7)
and http.client.HTTPConnection._set_content_length (Python 3.3)

there are something like that :

        try:
            thelen = str(len(body))
        except TypeError as te:
            # If this is a file-like object, try to
            # fstat its file descriptor
            try:
                thelen = str(os.fstat(body.fileno()).st_size)
            except (AttributeError, OSError):
                # Don't send a length if this failed
                if self.debuglevel > 0: print("Cannot stat!!")


If I put StringIO object in body and I do :

>>> len(body)
AttributeError: StringIO instance has no attribute '__len__'

I haven't TypeError.

I think we need to replace :

        try:
            thelen = str(len(body))
        except TypeError as te:

by :

        if hasattr(body, "read"):
           ... # it's file-like object
        else:
           ... # it's string object

What do you think about ?

----------
components: Library (Lib)
messages: 138264
nosy: harobed
priority: normal
severity: normal
status: open
title: in HTTPConnection the are len(body) and TypeError catch exception to detect if body is file like object, this hack do work with StringIO object
versions: Python 2.6, Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12327>
_______________________________________

From report at bugs.python.org  Mon Jun 13 19:55:56 2011
From: report at bugs.python.org (harobed)
Date: Mon, 13 Jun 2011 17:55:56 +0000
Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up by
	f.read() return bad result
In-Reply-To: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za>
Message-ID: <1307987756.07.0.261179264931.issue8260@psf.upfronthosting.co.za>


harobed <stephane at harobed.org> added the comment:

Up, I think this patch isn't applied in Python 3.3a0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8260>
_______________________________________

From report at bugs.python.org  Mon Jun 13 20:31:05 2011
From: report at bugs.python.org (Torsten Landschoff)
Date: Mon, 13 Jun 2011 18:31:05 +0000
Subject: [issue12306] zlib: Expose zlibVersion to query runtime version of zlib
In-Reply-To: <1307667064.6.0.30417035015.issue12306@psf.upfronthosting.co.za>
Message-ID: <1307989865.44.0.829799362578.issue12306@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

Here is an updated patch:

 * Function zlibVersion() replaced by module-level constant ZLIB_RUNTIME_VERSION
 * Added documentation (with versionadded: 3.3)

----------
Added file: http://bugs.python.org/file22343/zlib_runtime_version.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12306>
_______________________________________

From report at bugs.python.org  Mon Jun 13 20:51:52 2011
From: report at bugs.python.org (Torsten Landschoff)
Date: Mon, 13 Jun 2011 18:51:52 +0000
Subject: [issue12306] zlib: Expose zlibVersion to query runtime version of zlib
In-Reply-To: <1307667064.6.0.30417035015.issue12306@psf.upfronthosting.co.za>
Message-ID: <1307991112.42.0.547018854856.issue12306@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

Documentation for ZLIB_VERSION.

I just notice that it makes no sense to add the version info to that section. Feel free to move the two snippets.

I added a versionadded tag here as well (ZLIB_VERSION was already in Python 1.5). Is there any old release for that versionadded tags should be removed?

----------
Added file: http://bugs.python.org/file22344/zlib_version_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12306>
_______________________________________

From report at bugs.python.org  Mon Jun 13 20:53:16 2011
From: report at bugs.python.org (sbt)
Date: Mon, 13 Jun 2011 18:53:16 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>
Message-ID: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>


New submission from sbt <shibturn at gmail.com>:

There are some problems with the new Windows overlapped implementation
of PipeConnection in the default branch.

1) poll(0) can return False when an empty string is in the pipe: if
   the next message in the pipe is b"" then PeekNamedPipe() returns
   (0, 0) which is indistiguishable from the case where the pipe is
   empty.

   This affects versions 2.6-3.2 of Python on Windows as well.  For
   old versions I would just document the fact that poll() will fail
   to see that there is data in the pipe if the next message is an
   empty string.  In practice this is not a big deal since pipes are
   primarily used for pickled objects which will never be the empty
   string.

2) _poll() forgets to check self._buffered, so it can return False
   even if there is buffered data.

3) Even if (2) is fixed, _poll() with a non-zero timeout can mess up
   message boundaries if the pipe contains messages of length zero or
   one.  To fix this overlapped_GetOverlappedResult() needs to be
   changed to not swallow and forget ERROR_MORE_DATA errors.

4) In _poll() there is a race condition: if the read operation
   completes after WaitForMultipleObjects() timesout, but before the
   operation is cancelled, then the data read will be discarded.

5) The code assumes that if CancelIo()/CancelIoEx() returns
   successfully then the OVERLAPPED structure and associated buffer
   may be deallocated immediately.  But the documentation says that if
   CancelIo()/CancelIoEx() succeeds then cancellation has only been
   *requested*:

     http://msdn.microsoft.com/en-us/library/aa363792%28v=vs.85%29.aspx

     If [CancelIoEx()] succeeds, the return value is nonzero. The
     cancel operation for all pending I/O operations issued by the
     calling thread for the specified file handle was successfully
     *requested*. The application must not free or reuse the
     OVERLAPPED structure associated with the canceled I/O operations
     until they have *completed*. The thread can use the
     GetOverlappedResult function to determine when the I/O operations
     themselves have been completed.

   We should wait for cancellation to *complete* by using
   GetOverlappedResult(..., TRUE), otherwise we risk a crash.  If the
   operation was cancelled then FALSE is returned with GetLastError()
   == ERROR_OPERATION_ABORTED.

   I would suggest making it a programming error for the overlapped
   object to be deallocated while the operation is still pending, and
   to print a RuntimeError if that happens.  (This does not prevent us
   from still trying to prevent a crash using CancelIoEx().)

6) Not a bug exactly, but poll(timeout) is no longer interruptible
   with Ctrl-C.  This also means that Queue.get() is no longer
   interruptible.

--

The unit tests attached pass on Unix.  On Windows versions up to 3.2,
only test_empty_string fails.  On Windows version 3.3 all three fail.

----------
components: Extension Modules
files: test_pipe_poll.py
messages: 138268
nosy: jnoller, pitrou, sbt
priority: normal
severity: normal
status: open
title: multiprocessing's overlapped PipeConnection on Windows
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22345/test_pipe_poll.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Mon Jun 13 21:02:43 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jun 2011 19:02:43 +0000
Subject: [issue12141] sysconfig.get_config_vars('srcdir') fails in specific
	cases
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1307991763.17.0.967615451377.issue12141@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Here are patches to install a copy of xxmodule.c in the distutils tests directory (for 3.3, 3.2, and 2.7) and a copy in packaging tests for 3.3.  With them in place, test_build_ext/test_command_build_ext now executes when the tests are run from an installed Python where no source directory is available and each test case run copies the c file into its temp dir.
 
Currently, those test are being silently skipped in the installed case or, worse, picking up the wrong version of xxmodule.c depending on what sysconfig.get_config_vars('srcdir') returns (this happened to me when I reused a source directory name in some builds).   For 3.2, a patch is included to backport the Distutils part of the fix for issue12132.

----------
components: +Distutils, Distutils2
keywords: +patch
nosy: +alexis
stage:  -> patch review
Added file: http://bugs.python.org/file22346/issue12141_3x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Mon Jun 13 21:03:37 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jun 2011 19:03:37 +0000
Subject: [issue12141] sysconfig.get_config_vars('srcdir') fails in specific
	cases
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1307991817.61.0.897700793987.issue12141@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file22347/issue12132_backport_32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Mon Jun 13 21:04:13 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jun 2011 19:04:13 +0000
Subject: [issue12141] sysconfig.get_config_vars('srcdir') fails in specific
	cases
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1307991853.45.0.939485268712.issue12141@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file22348/issue12141_32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Mon Jun 13 21:04:48 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jun 2011 19:04:48 +0000
Subject: [issue12141] sysconfig.get_config_vars('srcdir') fails in specific
	cases
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1307991888.93.0.70811653255.issue12141@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file22349/issue12141_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Mon Jun 13 21:10:36 2011
From: report at bugs.python.org (sbt)
Date: Mon, 13 Jun 2011 19:10:36 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>
Message-ID: <1307992236.8.0.427435085055.issue12328@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

The attached patch hopefully fixes problems (1)-(5), but I have never used overlapped I/O before.  test_pipe_poll.py passes with these changes.

----------
keywords: +patch
Added file: http://bugs.python.org/file22350/pipe_poll.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Mon Jun 13 21:11:06 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 13 Jun 2011 19:11:06 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1307992266.06.0.581304507856.issue12326@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I suggest to change sys.platform to 'linux' in future releases (3.3). For bugfix releases (2.7, 3.2), I'd keep it as 'linux2' even on Linux 3. For security-only releases (2.6, 3.1), no change should be made.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Jun 13 21:31:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jun 2011 19:31:20 +0000
Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up by
	f.read() return bad result
In-Reply-To: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za>
Message-ID: <1307993480.26.0.820458324106.issue8260@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/issue8260>
_______________________________________

From report at bugs.python.org  Mon Jun 13 21:36:36 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jun 2011 19:36:36 +0000
Subject: [issue12327] in HTTPConnection the are len(body) and TypeError catch
	exception to detect if body is file like object,
	this hack do work with StringIO object
In-Reply-To: <1307987409.37.0.379147237937.issue12327@psf.upfronthosting.co.za>
Message-ID: <1307993796.74.0.573049168051.issue12327@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

fileno and stat won't work on a StringIO object.  So StringIO would need to be special cased to call getvalue.

----------
nosy: +orsenthil, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12327>
_______________________________________

From report at bugs.python.org  Mon Jun 13 21:43:51 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jun 2011 19:43:51 +0000
Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up by
	f.read() return bad result
In-Reply-To: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za>
Message-ID: <1307994231.02.0.961088484898.issue8260@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

According to this ticket it hasn't been applied anywhere yet (a message will be posted here when it is).

----------
nosy: +r.david.murray
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8260>
_______________________________________

From report at bugs.python.org  Mon Jun 13 21:45:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jun 2011 19:45:54 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1307983266.82.0.770300482221.issue12084@psf.upfronthosting.co.za>
Message-ID: <1307994351.26312.1.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Here's a cleaned up patch which includes the test and lstat change
> Victor mentioned.

The test pass on Windows Seven 64 bits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Mon Jun 13 21:53:31 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 13 Jun 2011 19:53:31 +0000
Subject: [issue7860] 32-bit Python on 64-bit Windows reports incorrect
	architecture
In-Reply-To: <1265393270.5.0.356323623138.issue7860@psf.upfronthosting.co.za>
Message-ID: <1307994811.36.0.121138138735.issue7860@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/issue7860>
_______________________________________

From report at bugs.python.org  Mon Jun 13 21:56:53 2011
From: report at bugs.python.org (harobed)
Date: Mon, 13 Jun 2011 19:56:53 +0000
Subject: [issue12327] in HTTPConnection the are len(body) and TypeError catch
	exception to detect if body is file like object,
	this hack do work with StringIO object
In-Reply-To: <1307987409.37.0.379147237937.issue12327@psf.upfronthosting.co.za>
Message-ID: <1307995013.43.0.750354671646.issue12327@psf.upfronthosting.co.za>


harobed <stephane at harobed.org> added the comment:

> fileno and stat won't work on a StringIO object.  So StringIO would need to be special cased to call getvalue.

Yes, but it isn't important in chunk transfer encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12327>
_______________________________________

From report at bugs.python.org  Mon Jun 13 22:42:21 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jun 2011 20:42:21 +0000
Subject: [issue12327] in HTTPConnection the are len(body) and TypeError catch
	exception to detect if body is file like object,
	this hack do work with StringIO object
In-Reply-To: <1307987409.37.0.379147237937.issue12327@psf.upfronthosting.co.za>
Message-ID: <1307997741.49.0.646628221637.issue12327@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

But if the len information is available, why not return it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12327>
_______________________________________

From report at bugs.python.org  Mon Jun 13 22:42:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jun 2011 20:42:47 +0000
Subject: [issue12327] in HTTPConnection the are len(body) and TypeError catch
	exception to detect if body is file like object,
	this hack do work with StringIO object
In-Reply-To: <1307987409.37.0.379147237937.issue12327@psf.upfronthosting.co.za>
Message-ID: <1307997767.47.0.0556149678581.issue12327@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12327>
_______________________________________

From report at bugs.python.org  Mon Jun 13 23:10:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 13 Jun 2011 21:10:53 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <E1QWEPL-0000qR-Ou@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1a3e8db28d49 by Brian Curtin in branch '3.2':
Fix #12084. os.stat on Windows wasn't working properly with relative symlinks.
http://hg.python.org/cpython/rev/1a3e8db28d49

New changeset c04c55afbf81 by Brian Curtin in branch 'default':
Merge from 3.2 for Issue #12084.
http://hg.python.org/cpython/rev/c04c55afbf81

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Mon Jun 13 23:13:45 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jun 2011 21:13:45 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1307999625.05.0.693048276105.issue9516@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

There are several issues here now.

With the patches as now applied, when running the tests with standard OS X installer Pythons, I saw occasional failures of the new test_deployment_target test case ("Unexpected target").   After ensuring that the build_ext tests actually are executed consistently (see the patches for Issue12141), I found that the test case failed consistently when test_distutils was run after test___all__, which is the default.  There was also a telltale warning that test___all__ altered the execution environment.  After investigating, I've come to the conclusion that the root cause of this test failure *and* of the original reported problem in this issue is the original implementation of forcing MACOSX_DEPLOYMENT_TARGET way back in r38123.

The main problem with r38123 is that, while the issue needing fixing is limited to Distutils-spawned build steps, the solution unpredictably can modify the environment of *all* subprocesses (as Ronald noted earlier in msg114195):

>>> import os
>>> os.system('echo $MACOSX_DEPLOYMENT_TARGET')

0
>>> import distutils.command.build
>>> os.system('echo $MACOSX_DEPLOYMENT_TARGET')
10.6
0

The modification occurs in distutils.sysconfig._init_posix when distutils.sysconfig is imported so the env change can be a side-effect of importing other distutils modules, like above.  This behavior has been the case since r38123 but its effects were somewhat masked within the Python interpreter process by the use of os.putenv.  Now that the patches for this issue replaced os.putenv with setting os.environ directly, the changed MACOSX_DEPLOYMENT_TARGET is now visible in the interpreter, too.  And that's the cause of the new test___all__ "altered the execution environment" message.  Running test___all__ causes distutils.sysconfig to be imported which causes the _init_posix one-time initialization to take place which will set MACOSX_DEPLOYMENT_TARGET (if it wasn't already set externally).  Regrtest now sees the change after running test___all__ and restores the original environment thereby deleting MACOSX_DEPLOYMENT_TARGET.  Because _init_posix is only run once, test_distutils fails afterwards because MACOSX_DEPLOYMENT_TARGET is no longer set and will never be set.

So I am now convinced that, indeed, the right solution is to only set MACOSX_DEPLOYMENT_TARGET in the Distutils-spawned processes.  Setting it globally is too fragile and has unintended side-effects (like in the reported problems earlier in this issue).

Beyond that there are some issues with the new test cases.  As it stands, the new test_deployment_target test case tries to run two subtests but the second doesn't actually work: distutils.build_ext doesn't bother recompiling it since the object file leftover from the first subtest appears to be up-to-date.  Also the test cases do not fully test the intended behavior of the deployment target processing:  allowing the deployment target to be overridden to be equal or greater than that of the interpreter build but not less.

Another issue is that with packaging now landed in the default branch (for 3.3), similar code and tests are needed there.  ?ric ported the new test cases but distutils.sysconfig does not exist in packaging: it uses the standard sysconfig.  So there is currently no deployment target checking or setting (what's done in distutils.sysconfig._init_posix) at all when using packaging.

The attached patches for 3.3, 3.2, and 2.7 try to address all these issues:
 - The deployment target setting code is removed from
   distutils.sysconfig._init_posix.
 - Distutils.spawn is modified to set the appropriate deployment
   target in the environment of spawned build subprocesses.
 - In test_build_ext, test case test_deployment_target is replaced
   by three new test cases: test_deployment_target_default,
   test_deployment_target_too_low,
   and test_deployment_target_higher_ok.
 - For 3.3 only, similar code is added to spawn in packaging.util
   and the test cases added to test_command_built_ext.

----------
resolution: fixed -> 
stage: committed/rejected -> patch review
Added file: http://bugs.python.org/file22351/issue9516_v3_test_distutils.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Mon Jun 13 23:14:12 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jun 2011 21:14:12 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1307999652.76.0.964595960459.issue9516@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file22352/issue9516_v3_distutils.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Mon Jun 13 23:14:54 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jun 2011 21:14:54 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1307999694.9.0.818508620646.issue9516@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file22353/issue9516_v3_test_distutils_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Mon Jun 13 23:15:25 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jun 2011 21:15:25 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1307999725.89.0.0287597894838.issue9516@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file22354/issue9516_v3_distutils_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Mon Jun 13 23:15:58 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jun 2011 21:15:58 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1307999758.08.0.41629900048.issue9516@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file22355/issue9516_v3_test_packaging.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Mon Jun 13 23:16:30 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jun 2011 21:16:30 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1307999790.86.0.901717719852.issue9516@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file22356/issue9516_v3_packaging.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Mon Jun 13 23:16:38 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 13 Jun 2011 21:16:38 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1307999798.21.0.7310103001.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Well apparently that killed the XP build bots. Does anyone currently have access to XP that could test this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Mon Jun 13 23:18:05 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 13 Jun 2011 21:18:05 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1307999798.21.0.7310103001.issue12084@psf.upfronthosting.co.za>
Message-ID: <A2A66F57550F50449EC38E10458E27FF1185101038@VA3DIAXVS381.RED001.local>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I'll take a look.

----------
Added file: http://bugs.python.org/file22357/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6448 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20110613/550cb345/attachment-0001.bin>

From report at bugs.python.org  Mon Jun 13 23:22:13 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 13 Jun 2011 21:22:13 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1308000133.28.0.23007865582.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

It has something to do with the GetFinalPathNameByHandle dance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Tue Jun 14 00:04:10 2011
From: report at bugs.python.org (Hans Peter de Koning)
Date: Mon, 13 Jun 2011 22:04:10 +0000
Subject: [issue12329] XHTML entity apos missing in htmlentitydefs
In-Reply-To: <1308002650.66.0.942536008369.issue12329@psf.upfronthosting.co.za>
Message-ID: <1308002650.66.0.942536008369.issue12329@psf.upfronthosting.co.za>


New submission from Hans Peter de Koning <hpdk at xs4all.nl>:

In module htmlentitydefs.py the following XHTML-1 entity is missing from 
dict name2codepoint:

    'apos':     0x0027, # apostrophe, U+0027 ISOnum

Above line should be added after line 72:
    'ang':      0x2220, # angle, U+2220 ISOamso

----------
components: Extension Modules
messages: 138282
nosy: hp.dekoning
priority: normal
severity: normal
status: open
title: XHTML entity apos missing in htmlentitydefs
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12329>
_______________________________________

From report at bugs.python.org  Tue Jun 14 00:20:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 13 Jun 2011 22:20:06 +0000
Subject: [issue12329] XHTML entity apos missing in htmlentitydefs
In-Reply-To: <1308002650.66.0.942536008369.issue12329@psf.upfronthosting.co.za>
Message-ID: <1308003606.83.0.412411050883.issue12329@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Library (Lib) -Extension Modules
keywords: +easy
nosy: +eric.araujo, ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12329>
_______________________________________

From report at bugs.python.org  Tue Jun 14 00:29:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jun 2011 22:29:25 +0000
Subject: [issue12141] sysconfig.get_config_vars('srcdir') fails in specific
	cases
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1308004165.13.0.0712642219266.issue12141@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Is it really necessary to copy this file?  I haven't looked at the tests, but I'm wondering if they are using xxmodule.c only because it already existed.  Could the test instead use a much simpler .c file that it creates on the fly?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Tue Jun 14 00:37:47 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jun 2011 22:37:47 +0000
Subject: [issue12141] sysconfig.get_config_vars('srcdir') fails in specific
	cases
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1308004667.3.0.512569665682.issue12141@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I think one of the objectives of the test is to see that it works with the C API of that particular Python release as captured in its version of xxmodule.c.  And, while it could be argued that both distutils and packaging don't need their own copies, I think it is cleaner to keep the two testing environment uncoupled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Tue Jun 14 00:46:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Jun 2011 22:46:10 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>
Message-ID: <1308005157.3662.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hello,

Thanks for the patch.

>    I would suggest making it a programming error for the overlapped
>    object to be deallocated while the operation is still pending, and
>    to print a RuntimeError if that happens.  (This does not prevent us
>    from still trying to prevent a crash using CancelIoEx().)

Sounds ok to me.

> 6) Not a bug exactly, but poll(timeout) is no longer interruptible
>    with Ctrl-C.  This also means that Queue.get() is no longer
>    interruptible.

There is infrastructure in _multiprocessing to handle Ctrl-C. Look for
"sigint_event" in Modules/_multiprocessing/*. This could be the topic of
a separate issue and patch.

> The unit tests attached pass on Unix.  On Windows versions up to 3.2,
> only test_empty_string fails.  On Windows version 3.3 all three fail.

Could you make the tests part of Lib/test/test_multiprocessing.py?

Also, what is the rationale for the following change:

-            elif timeout == 0.0:
+            elif timeout == 0.0 and nleft != 0:
                 return False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Tue Jun 14 01:28:20 2011
From: report at bugs.python.org (Julian)
Date: Mon, 13 Jun 2011 23:28:20 +0000
Subject: [issue12330] Named set methods on collections.Set and dict view
	objects
In-Reply-To: <1308007700.37.0.290981721685.issue12330@psf.upfronthosting.co.za>
Message-ID: <1308007700.37.0.290981721685.issue12330@psf.upfronthosting.co.za>


New submission from Julian <Julian+Python.org at GrayVines.com>:

collections.Set / collections.MutableSet do not provide any of the named set methods, nor do dict view objects (neither as viewkeys and friends create them nor in py3). They obviously implement the operator methods correctly, but besides the fact that they're not fully implementing the set API, .union, .difference, and .intersection, for example, take *args to do arbitrary unions / difference / intersections, so there's at least one functionality gap too (nothing a for loop can't fix but, yeah). I've attached a very quick example diff'ing the methods which I ran on 2.7 and 3.2.


In searching around for a reason, or at least some documentation or acknowledgement that this is intentional, I see there's an offhand comment on Issue7771 (I apologize in advance if this didn't deserve its own ticket then). Issue9212 was accepted as "an oversight" and is related, so I hope that it's worth the clarification as to whether 1. we (you :) are planning / willing to do this fix on 2.7, or 3.2, or 2. if this is desired for some reason, in which case consider this simply a documentation request and perhaps a dupe of 7771 then.

Now that I've been long winded thanks for your time :).

----------
components: Library (Lib)
files: namedmeths.py
messages: 138286
nosy: Julian
priority: normal
severity: normal
status: open
title: Named set methods on collections.Set and dict view objects
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file22358/namedmeths.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12330>
_______________________________________

From report at bugs.python.org  Tue Jun 14 01:39:41 2011
From: report at bugs.python.org (Julian)
Date: Mon, 13 Jun 2011 23:39:41 +0000
Subject: [issue12330] Named set methods on collections.Set and dict view
	objects
In-Reply-To: <1308007700.37.0.290981721685.issue12330@psf.upfronthosting.co.za>
Message-ID: <1308008381.23.0.335660318329.issue12330@psf.upfronthosting.co.za>


Changes by Julian <Julian+Python.org at GrayVines.com>:


----------
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12330>
_______________________________________

From report at bugs.python.org  Tue Jun 14 01:48:06 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jun 2011 23:48:06 +0000
Subject: [issue12330] Named set methods on collections.Set and dict view
	objects
In-Reply-To: <1308007700.37.0.290981721685.issue12330@psf.upfronthosting.co.za>
Message-ID: <1308008886.82.0.553943685689.issue12330@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

IIUC, collections.Set is, by definition, the full 'set' API.  The fact that the set builtin implements some additional methods is a convenience.

----------
nosy: +r.david.murray, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12330>
_______________________________________

From report at bugs.python.org  Tue Jun 14 01:48:48 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 13 Jun 2011 23:48:48 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1308008928.65.0.46332383197.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

How about this patch?

We yield the GIL in posix_do_stat, so as Antoine pointed out in IRC, we were calling PyErr_SetString without having the GIL. I think this is the correct fix as I've stepped through the code in Visual Studio, forcing it to take this branch when on Win7, but I don't currently have the ability to run on XP.

----------
Added file: http://bugs.python.org/file22359/issue12084_XP.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Tue Jun 14 01:53:49 2011
From: report at bugs.python.org (Julian)
Date: Mon, 13 Jun 2011 23:53:49 +0000
Subject: [issue12330] Named set methods on collections.Set and dict view
	objects
In-Reply-To: <1308007700.37.0.290981721685.issue12330@psf.upfronthosting.co.za>
Message-ID: <1308009229.95.0.235390735299.issue12330@psf.upfronthosting.co.za>


Julian <Julian+Python.org at GrayVines.com> added the comment:

Oh boy. Reading the comment in Issue9212 more carefully now that you said that I see that Mr. Hettinger said exactly that. I apologize for missing it the first time.

"Concrete classes are allowed to have more features than the corresponding ABC.  The ABCs are not intended to be full-featured; instead, they specify the part of the API that will be guaranteed.  For example, the union() method for built-in sets allows two or more set arguments, but the corresponding method for the ABC is limited to two arguments.  This was an intentional difference, designed to make it easier for people to implement a Set class."

I suppose I should close this, unless there's some hope perhaps of some elaboration on that last line. Why couldn't collections provide the named methods too (in what way is this "easier"?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12330>
_______________________________________

From report at bugs.python.org  Tue Jun 14 01:55:25 2011
From: report at bugs.python.org (Julian)
Date: Mon, 13 Jun 2011 23:55:25 +0000
Subject: [issue12330] Named set methods on collections.Set and dict view
	objects
In-Reply-To: <1308007700.37.0.290981721685.issue12330@psf.upfronthosting.co.za>
Message-ID: <1308009325.92.0.714523792123.issue12330@psf.upfronthosting.co.za>


Changes by Julian <Julian+Python.org at GrayVines.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12330>
_______________________________________

From report at bugs.python.org  Tue Jun 14 02:24:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Jun 2011 00:24:22 +0000
Subject: [issue12330] Named set methods on collections.Set and dict view
	objects
In-Reply-To: <1308007700.37.0.290981721685.issue12330@psf.upfronthosting.co.za>
Message-ID: <1308011062.94.0.560589474676.issue12330@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

collections.Set (in python 3.3, collections.abc.Set) is the *definition* of the minimal API.  To construct a class that conforms to the minimal definition is certainly easier than constructing one that supports all of the methods that the set builtin does.

I suppose it would be possible for the collections module to provide a 'SetMixin' or some such that provided implementations of the other methods in terms of the required methods, but that would definitely be a feature request, and probably a topic that should be discussed first on the python-ideas mailing list.

----------
resolution:  -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12330>
_______________________________________

From report at bugs.python.org  Tue Jun 14 06:43:14 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 14 Jun 2011 04:43:14 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1308026594.8.0.294756480505.issue12326@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Jun 14 07:08:52 2011
From: report at bugs.python.org (Matt Joiner)
Date: Tue, 14 Jun 2011 05:08:52 +0000
Subject: [issue9674] make install DESTDIR=/home/blah fails when the prefix
	specified is /
In-Reply-To: <1282677588.85.0.771807305266.issue9674@psf.upfronthosting.co.za>
Message-ID: <1308028132.75.0.458482039128.issue9674@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

Just ran into this bug myself with 3.2. Apparently this patch works: http://groups.google.com/group/comp.lang.python/msg/bd8818ab9d4af8d7

----------
nosy: +anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9674>
_______________________________________

From report at bugs.python.org  Tue Jun 14 07:37:16 2011
From: report at bugs.python.org (Matt Joiner)
Date: Tue, 14 Jun 2011 05:37:16 +0000
Subject: [issue9674] make install DESTDIR=/home/blah fails when the prefix
	specified is /
In-Reply-To: <1282677588.85.0.771807305266.issue9674@psf.upfronthosting.co.za>
Message-ID: <1308029836.01.0.501876055429.issue9674@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

Attached a patch that fixes it, only the line numbers have changed from Martin v. Loewis's patch. Used on 3.2.

----------
Added file: http://bugs.python.org/file22360/fix-root-prefix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9674>
_______________________________________

From report at bugs.python.org  Tue Jun 14 07:38:17 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 14 Jun 2011 05:38:17 +0000
Subject: [issue12174] Multiprocessing logging levels unclear
In-Reply-To: <1307981761.94.0.188152814616.issue12174@psf.upfronthosting.co.za>
Message-ID: <20110614053816.GA8256@colossus>


Petri Lehtinen <petri at digip.org> added the comment:

R. David Murray wrote:
> I think it would be good to mention the numeric levels in the text as well (in parenthesis, perhaps), unless the rest of the logging docs no longer refer to the numeric levels.

AFAICS, there are no numbers in the logging docs anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12174>
_______________________________________

From report at bugs.python.org  Tue Jun 14 07:38:29 2011
From: report at bugs.python.org (Matt Joiner)
Date: Tue, 14 Jun 2011 05:38:29 +0000
Subject: [issue9674] make install DESTDIR=/home/blah fails when the prefix
	specified is /
In-Reply-To: <1282677588.85.0.771807305266.issue9674@psf.upfronthosting.co.za>
Message-ID: <1308029909.92.0.10861714455.issue9674@psf.upfronthosting.co.za>


Changes by Matt Joiner <anacrolix at gmail.com>:


----------
components: +Build, Library (Lib)
nosy: +alexis
type: behavior -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9674>
_______________________________________

From report at bugs.python.org  Tue Jun 14 07:47:53 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 14 Jun 2011 05:47:53 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1308030473.25.0.530238569697.issue12326@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This change is reasonable for the long term.  But it *will* break a lot of code.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Jun 14 08:11:20 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 14 Jun 2011 06:11:20 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1308030473.25.0.530238569697.issue12326@psf.upfronthosting.co.za>
Message-ID: <4DF6FB86.4070500@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> This change is reasonable for the long term.  But it *will* break a lot of code.

[If you favor a specific change, please indicate what that is. I'm
assuming you support my proposal for the moment :-]

I agree it will break a lot of code, but it's also somewhat urgent
because we will get 'linux3' if we don't act, which will also break
a lot of code (but more subtly, since people testing their code may
do so on Linux 2, only to get bug reports that it breaks on "some"
Linux systems). I'm sure Linus Torvalds is fully aware of the possible
consequences of the version change, and just accepted the breakage
that this would cause.

It's important that we set a policy before the Linux distributions
do (which may end up choosing different policies). We don't actually
have to *release* this change quickly, since Linux distributions
who release 3.x kernels will fix their Python packages themselves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Jun 14 08:15:58 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 14 Jun 2011 06:15:58 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
	"chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1308032158.52.0.202584901777.issue12319@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

harobed wrote:
> I use http.client in WebDAV client.
>
> Mac OS X Finder WebDAV client perform all his request in "chunk" mode : PUT and GET.
>
> Here, I use http.client to simulate Mac OS X Finder WebDAV client.

Now I'm confused. Per the HTTP specification, GET requests don't have
a body, so "Transfer-Encoding: chunked" doesn't apply to them.

Are you sure you don't confuse with the response that the server
sends? In responses, "Transfer-Encoding: chunked" is very common.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12319>
_______________________________________

From report at bugs.python.org  Tue Jun 14 08:26:12 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 14 Jun 2011 06:26:12 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1308032772.11.0.641424782642.issue10224@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Actually, on Windows, PYTHON is typically not set at all. So the likelihood of it being set to Python 3 is very low, unless you are trying to build Python documentation from time to time.

Sye: I fail to see the point of your patch. sphinx-build.py already issues an error message - why do you need more error messages?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Tue Jun 14 08:27:16 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 14 Jun 2011 06:27:16 +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: <1308032836.2.0.474859470752.issue11934@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11934>
_______________________________________

From report at bugs.python.org  Tue Jun 14 08:28:02 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 14 Jun 2011 06:28:02 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1308032882.41.0.529050387493.issue12326@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The change to sys.platform=='linux' would break code even on current platforms.
OTOH, we have sys.platform=='win32' even on Windows 64bit; would this favor keeping 'linux2' on all versions of Linux as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Jun 14 08:55:47 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 14 Jun 2011 06:55:47 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1308032882.41.0.529050387493.issue12326@psf.upfronthosting.co.za>
Message-ID: <4DF705F1.9010501@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The change to sys.platform=='linux' would break code even on current platforms.

Correct. Compared to introducing 'linux3', I consider this the better
change - it likely breaks earlier (i.e. when porting to Python 3.3).

> OTOH, we have sys.platform=='win32' even on Windows 64bit; would this
> favor keeping 'linux2' on all versions of Linux as well?

While this has better compatibility, it's also a constant source of
irritation. Introducing 'win64' would have been a worse choice (just
as introducing 'linux3' would: incompatibility for no gain, since
the distinction between win32 and win64, from a Python POV, is
irrelevant). Plus, Microsoft dislikes the term Win64 somewhat, and
rather wants people to refer to the "Windows API".

I personally disliked 'linux2' when it was introduced, for its
incompatibilities. Anticipating that, some day, we may have 'Linux 4',
and so on, I still claim it is better to fix this now. We could even
come up with a 2to3 fixer for people who dual-source their code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Jun 14 09:00:50 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 14 Jun 2011 07:00:50 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <4DF6FB86.4070500@v.loewis.de>
Message-ID: <BANLkTimY3xfWYL92LXcWgBn-i6jENYLYeQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I'm sure Linus Torvalds is fully aware of the possible
> consequences of the version change, and just accepted the breakage
> that this would cause.

Any application relying on sys.platform == 'linux2' is already broken.
It's exactly the same if an application checks for 'freebsd6' or
'openbsd4' : if you want to check for a specific operating system,
there's already POSIX' struct utsname sysname field, i.e. uname()[0].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Jun 14 10:23:46 2011
From: report at bugs.python.org (Dan Kenigsberg)
Date: Tue, 14 Jun 2011 08:23:46 +0000
Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in
	select()"
In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za>
Message-ID: <1308039826.56.0.816524752441.issue10527@psf.upfronthosting.co.za>


Dan Kenigsberg <danken at redhat.com> added the comment:

I would rate this issue as a performance bug, not a mere feature request. If the python process has more than 1023 open file descriptors, multiprocessing.Pipe.poll() becomes unusable. This is a serious barrier to using multiprocessing in a complex server.

----------
nosy: +danken
type: feature request -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10527>
_______________________________________

From report at bugs.python.org  Tue Jun 14 10:25:05 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 14 Jun 2011 08:25:05 +0000
Subject: [issue12331] lib2to3 tests write into protected directory
In-Reply-To: <1308039905.35.0.844130092935.issue12331@psf.upfronthosting.co.za>
Message-ID: <1308039905.35.0.844130092935.issue12331@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

Some of the tests for lib2to3 write into folders which are protected in an installed Python. This means that regression tests fail when run on an installed Python, even though they run wihtout these errors on a source build. I think writes should be done into temp files, so that you can run regressions on installed Pythons.

Example failure:

======================================================================
ERROR: test_refactor_file (lib2to3.tests.test_refactor.TestRefactoringTool)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python3.3/lib2to3/tests/test_refactor.py", line 190, in check_file_refactoring
    rt.refactor_file(test_file, True)
  File "/usr/local/lib/python3.3/lib2to3/refactor.py", line 353, in refactor_file
    write=write, encoding=encoding)
  File "/usr/local/lib/python3.3/lib2to3/refactor.py", line 518, in processed_file
    self.write_file(new_text, filename, old_text, encoding)
  File "/usr/local/lib/python3.3/lib2to3/refactor.py", line 530, in write_file
    f = _open_with_encoding(filename, "w", encoding=encoding)
IOError: [Errno 13] Permission denied: '/usr/local/lib/python3.3/lib2to3/tests/data/fixers/parrot_example.py'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.3/lib2to3/tests/test_refactor.py", line 200, in test_refactor_file
    self.check_file_refactoring(test_file, _DEFAULT_FIXERS)
  File "/usr/local/lib/python3.3/lib2to3/tests/test_refactor.py", line 194, in check_file_refactoring
    with open(test_file, "wb") as fp:
IOError: [Errno 13] Permission denied: '/usr/local/lib/python3.3/lib2to3/tests/data/fixers/parrot_example.py'

----------
components: 2to3 (2.x to 3.0 conversion tool), Tests
messages: 138302
nosy: benjamin.peterson, vinay.sajip
priority: normal
severity: normal
status: open
title: lib2to3 tests write into protected directory
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12331>
_______________________________________

From report at bugs.python.org  Tue Jun 14 10:25:48 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 14 Jun 2011 08:25:48 +0000
Subject: [issue12331] lib2to3 tests write into protected directory
In-Reply-To: <1308039905.35.0.844130092935.issue12331@psf.upfronthosting.co.za>
Message-ID: <1308039948.63.0.352664301252.issue12331@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12331>
_______________________________________

From report at bugs.python.org  Tue Jun 14 10:27:29 2011
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 14 Jun 2011 08:27:29 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1308040049.89.0.51731187043.issue12084@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I tried issue12084_XP.diff, but os.stat()/os.lstat() always failed with following message because it raises exception on top of it when running on XP.

Python 3.2.1rc1+ (default, Jun 14 2011, 16:26:11) [MSC v.1200 32 bit (Intel)] on
 win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
[53981 refs]
>>> os.stat("src")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 127] ????????????????????: 'src'
[54014 refs]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Tue Jun 14 10:34:02 2011
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 14 Jun 2011 08:34:02 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1308040442.24.0.921376273108.issue12084@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I created several patches.
quick1.patch: os.stat() traverses junction on Vista/7, and raises error on XP.
quick2.patch: os.stat() never traverse junction on all windows.
quick3.patch: os.stat() should traverse junction os Vista/7, but doesn't on XP.

There are many patches because I don't know how to treat junction on os.stat().

----------
Added file: http://bugs.python.org/file22361/quick1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Tue Jun 14 10:34:46 2011
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 14 Jun 2011 08:34:46 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1308040486.49.0.466417859194.issue12084@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file22362/quick2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Tue Jun 14 10:35:25 2011
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 14 Jun 2011 08:35:25 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1308040525.31.0.822463153302.issue12084@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file22363/quick3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Tue Jun 14 11:12:28 2011
From: report at bugs.python.org (Erez Sh)
Date: Tue, 14 Jun 2011 09:12:28 +0000
Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in
	select()"
In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za>
Message-ID: <1308042748.35.0.655714983227.issue10527@psf.upfronthosting.co.za>


Erez Sh <erez27 at gmail.com> added the comment:

I support this change. Putting an arbitrary limitation on the amount of supported subprocesses is disastrous for complex software.

Gergely's patch seems good. I would only like to suggest a small cosmetic refinement to it, which removes some dead code.

----------
nosy: +Erez.Sh
Added file: http://bugs.python.org/file22364/multiproc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10527>
_______________________________________

From report at bugs.python.org  Tue Jun 14 11:13:13 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 14 Jun 2011 09:13:13 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <4DF705F1.9010501@v.loewis.de>
Message-ID: <4DF72625.5040009@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> The change to sys.platform=='linux' would break code even on current platforms.
> 
> Correct. Compared to introducing 'linux3', I consider this the better
> change - it likely breaks earlier (i.e. when porting to Python 3.3).
> 
>> OTOH, we have sys.platform=='win32' even on Windows 64bit; would this
>> favor keeping 'linux2' on all versions of Linux as well?
> 
> While this has better compatibility, it's also a constant source of
> irritation. Introducing 'win64' would have been a worse choice (just
> as introducing 'linux3' would: incompatibility for no gain, since
> the distinction between win32 and win64, from a Python POV, is
> irrelevant). Plus, Microsoft dislikes the term Win64 somewhat, and
> rather wants people to refer to the "Windows API".
> 
> I personally disliked 'linux2' when it was introduced, for its
> incompatibilities. Anticipating that, some day, we may have 'Linux 4',
> and so on, I still claim it is better to fix this now. We could even
> come up with a 2to3 fixer for people who dual-source their code.

I think we should consider adding a better mechanism and just
keep the old mechanism for determining sys.platform in place
(letting it break on Linux to raise awareness) and add a new better
attribute along the lines of what Martin suggested:

sys.system == 'linux', 'freebsd', 'openbsd', 'windows', etc.
              (without version)

and a new

sys.system_info == system release info (named) tuple similar to
                   sys.version_info

to query a specific system version.

As already noted, direct sys.platform testing already breaks for
OpenBSD, FreeBSD and probably a few other OSes as well with
every major OS release, so the Linux breakage is not really new
in any way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Jun 14 11:57:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Jun 2011 09:57:51 +0000
Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in
	select()"
In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za>
Message-ID: <1308045471.19.0.92440984834.issue10527@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10527>
_______________________________________

From report at bugs.python.org  Tue Jun 14 12:15:11 2011
From: report at bugs.python.org (Stephen White)
Date: Tue, 14 Jun 2011 10:15:11 +0000
Subject: [issue762963] timemodule.c: Python loses current timezone
Message-ID: <1308046511.67.0.298762740186.issue762963@psf.upfronthosting.co.za>


Stephen White <stephen-python.org at randomstuff.org.uk> added the comment:

Debian appear to have applied this patch, and it seems to be causing problems:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593461

----------
nosy: +Stephen.White

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue762963>
_______________________________________

From report at bugs.python.org  Tue Jun 14 12:28:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Jun 2011 10:28:39 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <4DF705F1.9010501@v.loewis.de>
Message-ID: <1308047301.3683.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > The change to sys.platform=='linux' would break code even on current platforms.
> 
> Correct. Compared to introducing 'linux3', I consider this the better
> change - it likely breaks earlier (i.e. when porting to Python 3.3).

FWIW, I also agree that sys.platform == 'linux' would be the better
choice. It seems there's little point having the kernel's major version
there. It's both disruptive and useless (because features are introduced
at any point, not just at new major versions).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Jun 14 12:34:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 14 Jun 2011 10:34:23 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1308047663.98.0.826366779911.issue12326@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/issue12326>
_______________________________________

From report at bugs.python.org  Tue Jun 14 12:48:19 2011
From: report at bugs.python.org (Jon Siddle)
Date: Tue, 14 Jun 2011 10:48:19 +0000
Subject: [issue762963] timemodule.c: Python loses current timezone
Message-ID: <1308048499.67.0.278555385849.issue762963@psf.upfronthosting.co.za>


Changes by Jon Siddle <js at corefiling.co.uk>:


----------
nosy: +jonsiddle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue762963>
_______________________________________

From report at bugs.python.org  Tue Jun 14 13:03:11 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 14 Jun 2011 11:03:11 +0000
Subject: [issue12331] lib2to3 and packaging tests fail because they write into
	protected directory
In-Reply-To: <1308039905.35.0.844130092935.issue12331@psf.upfronthosting.co.za>
Message-ID: <1308049391.56.0.526449556602.issue12331@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Some packaging tests also fail, for similar reasons:

======================================================================
ERROR: test_get_distinfo_file (packaging.tests.test_database.TestDistribution)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python3.3/packaging/tests/test_database.py", line 114, in setUp
    with open(record_file, 'w') as file:
IOError: [Errno 13] Permission denied: '/usr/local/lib/python3.3/packaging/tests/fake_dists/babar-0.1.dist-info/RECORD'

----------
components:  -2to3 (2.x to 3.0 conversion tool)
nosy: +eric.araujo
title: lib2to3 tests write into protected directory -> lib2to3 and packaging tests fail because they write into protected directory

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12331>
_______________________________________

From report at bugs.python.org  Tue Jun 14 13:14:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Jun 2011 11:14:12 +0000
Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in
	select()"
In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za>
Message-ID: <1308050052.26.0.036792482632.issue10527@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This code has changed a lot in Python 3.3 (it is now located in Lib/multiprocessing/connection.py). Can you post a patch against the development tip ("default" branch)?

See http://docs.python.org/devguide/setup.html if you need more information.

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10527>
_______________________________________

From report at bugs.python.org  Tue Jun 14 14:38:19 2011
From: report at bugs.python.org (Tim Lesher)
Date: Tue, 14 Jun 2011 12:38:19 +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: <1308055099.27.0.265473960077.issue11838@psf.upfronthosting.co.za>


Changes by Tim Lesher <tlesher at gmail.com>:


----------
nosy: +tlesher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11838>
_______________________________________

From report at bugs.python.org  Tue Jun 14 15:03:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Jun 2011 13:03:49 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
	"chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1308056629.54.0.8524502352.issue12319@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12319>
_______________________________________

From report at bugs.python.org  Tue Jun 14 15:21:25 2011
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 14 Jun 2011 13:21:25 +0000
Subject: [issue10897] UNIX mmap unnecessarily dup() file descriptor
In-Reply-To: <1294845379.76.0.427887707002.issue10897@psf.upfronthosting.co.za>
Message-ID: <1308057685.17.0.472428921305.issue10897@psf.upfronthosting.co.za>


Changes by Facundo Batista <facundo at taniquetil.com.ar>:


----------
nosy:  -facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10897>
_______________________________________

From report at bugs.python.org  Tue Jun 14 15:39:23 2011
From: report at bugs.python.org (Carmine Paolino)
Date: Tue, 14 Jun 2011 13:39:23 +0000
Subject: [issue12332] Float division
In-Reply-To: <1308058763.8.0.977949116716.issue12332@psf.upfronthosting.co.za>
Message-ID: <1308058763.8.0.977949116716.issue12332@psf.upfronthosting.co.za>


New submission from Carmine Paolino <paolino.carmine at alice.it>:

Trying to run this simple script:
for i in range(10):
    print(i*0.2)
when i is 3, the result given is 0.6000000000000001.
What could the problem be?

----------
components: Interpreter Core
messages: 138311
nosy: cancelliere
priority: normal
severity: normal
status: open
title: Float division
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12332>
_______________________________________

From report at bugs.python.org  Tue Jun 14 15:44:42 2011
From: report at bugs.python.org (Carmine Paolino)
Date: Tue, 14 Jun 2011 13:44:42 +0000
Subject: [issue12332] Float division
In-Reply-To: <1308058763.8.0.977949116716.issue12332@psf.upfronthosting.co.za>
Message-ID: <1308059082.71.0.169937806123.issue12332@psf.upfronthosting.co.za>


Carmine Paolino <paolino.carmine at alice.it> added the comment:

When I try to run 3*0.2 in Python shell or using an IDLE document, the result given is 0.6000000000000001.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12332>
_______________________________________

From report at bugs.python.org  Tue Jun 14 15:46:47 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 14 Jun 2011 13:46:47 +0000
Subject: [issue12332] Float division
In-Reply-To: <1308058763.8.0.977949116716.issue12332@psf.upfronthosting.co.za>
Message-ID: <1308059207.34.0.909618907417.issue12332@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Yep. See http://docs.python.org/tutorial/floatingpoint.html

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12332>
_______________________________________

From report at bugs.python.org  Tue Jun 14 15:57:40 2011
From: report at bugs.python.org (Oren Held)
Date: Tue, 14 Jun 2011 13:57:40 +0000
Subject: [issue11102] configure doesn't find "major()" on HP-UX v11.31
In-Reply-To: <1296677130.56.0.432506284039.issue11102@psf.upfronthosting.co.za>
Message-ID: <1308059860.95.0.728698087462.issue11102@psf.upfronthosting.co.za>


Oren Held <oren at held.org.il> added the comment:

Any tip on how to make this patch get committed? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11102>
_______________________________________

From report at bugs.python.org  Tue Jun 14 16:26:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Jun 2011 14:26:47 +0000
Subject: [issue12333] test_packaging failures under Solaris
In-Reply-To: <1308061607.43.0.119074494077.issue12333@psf.upfronthosting.co.za>
Message-ID: <1308061607.43.0.119074494077.issue12333@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The problem is that tearDown() tries to rmdir() the current directory, which is forbidden under Solaris and returns EINVAL:

>>> os.getcwd()
'/home/antoine/t/t'
>>> os.rmdir("/home/antoine/t/t")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument: '/home/antoine/t/t'
>>> os.chdir('..')
>>> os.rmdir("/home/antoine/t/t")
>>> 

Extract of rmdir (2) manpage:

     EINVAL          The directory to be removed is  the  current
                     directory, or the final component of path is
                     ".".

See e.g. http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x:

======================================================================
ERROR: test_cfg_to_args (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmpe5bnmg/tmp_41r35'

======================================================================
ERROR: test_change_root (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmptqqcy4/tmp8k_szg'

======================================================================
ERROR: test_convert_path (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmpz76w6g/tmpehqobf'

======================================================================
ERROR: test_dont_write_bytecode (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmpfou_50/tmp8m6foa'

======================================================================
ERROR: test_find_exe_version (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmp8qchh_/tmpask38f'

======================================================================
ERROR: test_find_packages (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmpm0qhvv/tmp8t42l2'

======================================================================
ERROR: test_get_compiler_versions (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmpou061r/tmph8fa0r'

======================================================================
ERROR: test_import_nested_first_time (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmp6iygts/tmpy8btph'

======================================================================
ERROR: test_newer (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmpkyznct/tmpfj4aiy'

======================================================================
ERROR: test_resolve_name (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmpz_s22i/tmp7am_yk'

======================================================================
ERROR: test_rfc822_escape (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmpbo_555/tmpnavzar'

======================================================================
ERROR: test_run_2to3_on_code (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmphtln_2/tmpib4b_x'

======================================================================
ERROR: test_run_2to3_on_doctests (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmpi1r8bp/tmp444dq2'

======================================================================
ERROR: test_server_empty_registration (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmpqy_wif/tmp7tbq0t'
/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/pypi/simple.py:86: ResourceWarning: unclosed <socket.socket object, fd=21, family=2, type=2, proto=6>
  return wrapped(self, *args, **kwargs)
Warning -- logging._handlerList was modified by test_packaging
test test_packaging failed -- multiple errors occurred

======================================================================
ERROR: test_server_registration (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmpink626/tmpzqcvqs'

======================================================================
ERROR: test_spawn (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmpohv3t5/tmpjpol8_'

======================================================================
ERROR: test_split_quoted (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmp00p03n/tmpvxwrl5'

======================================================================
ERROR: test_strtobool (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmppwqypq/tmp8vywqv'

----------
assignee: eric.araujo
components: Distutils2
messages: 138315
nosy: alexis, eric.araujo, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test_packaging failures under Solaris
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12333>
_______________________________________

From report at bugs.python.org  Tue Jun 14 16:30:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Jun 2011 14:30:52 +0000
Subject: [issue12331] lib2to3 and packaging tests fail because they write into
	protected directory
In-Reply-To: <1308039905.35.0.844130092935.issue12331@psf.upfronthosting.co.za>
Message-ID: <1308061852.97.0.0528162239044.issue12331@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> tarek
components: +Distutils2
nosy: +alexis, tarek
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12331>
_______________________________________

From report at bugs.python.org  Tue Jun 14 16:34:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Jun 2011 14:34:09 +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: <1308062049.19.0.292218426474.issue11934@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, using $(prefix)/include to fetch development headers sounds like the wrong strategy anyway. Just because you e.g. install into /usr/local doesn't mean your zlib is inside /usr/local too.

And if that makes people use our own zlib headers by mistake, then it's doubly wrong IMO.

----------
nosy: +loewis, pitrou
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11934>
_______________________________________

From report at bugs.python.org  Tue Jun 14 16:55:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 14:55:37 +0000
Subject: [issue12329] XHTML entity apos missing in htmlentitydefs
In-Reply-To: <1308002650.66.0.942536008369.issue12329@psf.upfronthosting.co.za>
Message-ID: <1308063337.04.0.198264283401.issue12329@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Please join the discussion on the already-opened report #11113.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> html.entities mapping dicts need updating?
type:  -> feature request
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12329>
_______________________________________

From report at bugs.python.org  Tue Jun 14 16:57:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 14:57:16 +0000
Subject: [issue11113] html.entities mapping dicts need updating?
In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>
Message-ID: <1308063436.42.0.613215441359.issue11113@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I just closed #12329 as a duplicate of this bug.  It requested the addition of the apos named entity reference.

TTBOMK, the html module (or htmlentitydefs in 2.x) doesn?t claim to support XHTML TTBOMK; an XML parser should be used for XHTML.  In HTML 4.01, apos is not defined, but it is in HTML5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11113>
_______________________________________

From report at bugs.python.org  Tue Jun 14 16:58:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 14:58:52 +0000
Subject: [issue12141] sysconfig.get_config_vars('srcdir') fails in specific
	cases
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1308063532.97.0.272608573515.issue12141@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Path LGTM.

Also +1 on keeping distutils and packaging wholly separate, including in tests infrastructure.  It?s just one file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Tue Jun 14 16:59:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 14:59:34 +0000
Subject: [issue12333] test_packaging failures under Solaris
In-Reply-To: <1308061607.43.0.119074494077.issue12333@psf.upfronthosting.co.za>
Message-ID: <1308063574.64.0.493738339768.issue12333@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m going to change directory before removing the temp dir.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12333>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:00:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 15:00:43 +0000
Subject: [issue12331] lib2to3 and packaging tests fail because they write into
	protected directory
In-Reply-To: <1308039905.35.0.844130092935.issue12331@psf.upfronthosting.co.za>
Message-ID: <1308063643.93.0.165726363577.issue12331@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This should not be too hard to fix: I?ll move the directory with the mock projects to a temp dir, add that to sys.path, and then we?ll be able to read and write.

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12331>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:04:04 2011
From: report at bugs.python.org (Reinhard Engel)
Date: Tue, 14 Jun 2011 15:04:04 +0000
Subject: [issue12334] Strange sort error
In-Reply-To: <1308063844.27.0.122131679299.issue12334@psf.upfronthosting.co.za>
Message-ID: <1308063844.27.0.122131679299.issue12334@psf.upfronthosting.co.za>


New submission from Reinhard Engel <nc-engelre at netcologne.de>:

# Strange sort error
# lst1 and lst 2 produce different results, but should be same
# lst1 should sort by length of items, but doesn't, lst2 does!

lst0 = ['ab-get-ratings-max', 'ab-get-ratings-min', 'ab-rate-position', 'accum', 'add-cops', 'add-new-dice', 'add-passing-move', 'add-plants', 'add-two', 'add-widget']
print lst0
lst1 = sorted(lst0, lambda x, y: len(y) > len(x))
print lst1
lst2 = sorted(lst0, lambda x, y: len(y) - len(x))
print lst2

----------
messages: 138322
nosy: rengel
priority: normal
severity: normal
status: open
title: Strange sort error
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12334>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:06:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 14 Jun 2011 15:06:52 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <E1QWVCc-00009N-Lj@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 23e14af406df by Brian Curtin in branch 'default':
Merge 3.2 - update to the fix for #12084
http://hg.python.org/cpython/rev/23e14af406df

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:08:47 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 14 Jun 2011 15:08:47 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1308064127.13.0.077529340524.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I think quick3 is the way to go - checked in, we'll see how the buildbots react.

1524a60016d0 is the changeset for the 3.2 checkin (forgot to mention the issue# there)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:11:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 15:11:51 +0000
Subject: [issue7969] shutil.copytree error handling non-standard and partially
	broken
In-Reply-To: <1266617058.24.0.24785922897.issue7969@psf.upfronthosting.co.za>
Message-ID: <1308064311.24.0.564114119642.issue7969@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think it would be good.

----------
assignee: tarek -> eric.araujo
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7969>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:14:44 2011
From: report at bugs.python.org (Reinhard Engel)
Date: Tue, 14 Jun 2011 15:14:44 +0000
Subject: [issue12334] Strange sort error
In-Reply-To: <1308063844.27.0.122131679299.issue12334@psf.upfronthosting.co.za>
Message-ID: <1308064484.25.0.395639528896.issue12334@psf.upfronthosting.co.za>


Reinhard Engel <nc-engelre at netcologne.de> added the comment:

Sorry, oversaw silly error in comparison!

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12334>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:21:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 15:21:26 +0000
Subject: [issue9273] 2to3 to simultaneously do code and doctests
In-Reply-To: <1279295325.63.0.00955742679892.issue9273@psf.upfronthosting.co.za>
Message-ID: <1308064886.77.0.260915543268.issue9273@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

For the 2to3 support in the new packaging module (successor of distutils), we even do three passes: code, docstrings and doctest files.

----------
nosy: +eric.araujo
stage:  -> needs patch
title: 2to3 to simultaneously do code AND doctests -> 2to3 to simultaneously do code and doctests
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9273>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:23:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 15:23:33 +0000
Subject: [issue9363] data_files are not installed relative to sys.prefix
In-Reply-To: <1279926086.74.0.751307014326.issue9363@psf.upfronthosting.co.za>
Message-ID: <1308065013.74.0.23174462075.issue9363@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Do you have a script or test to reproduce the bug?  Otherwise I?ll try to write one.

----------
assignee: tarek -> eric.araujo
nosy: +eric.araujo
stage:  -> test needed
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9363>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:26:22 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 14 Jun 2011 15:26:22 +0000
Subject: [issue12334] Strange sort error
In-Reply-To: <1308063844.27.0.122131679299.issue12334@psf.upfronthosting.co.za>
Message-ID: <1308065182.32.0.913475763036.issue12334@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

... and you probably want

sorted(lst0, key=len, reverse=True)

anyway. :-)

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12334>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:26:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 15:26:38 +0000
Subject: [issue12207] Document ast.PyCF_ONLY_AST
In-Reply-To: <1306689830.34.0.885575322408.issue12207@psf.upfronthosting.co.za>
Message-ID: <1308065198.36.0.809808703591.issue12207@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Another bug requesting documentation for a compiler flag exposed by a module: #1612012.

> If possible, I would have the index point to the first current
> sentence, which also mentions .parse() as an alternative.
This should be possible: http://sphinx.pocoo.org/markup/para.html#directive-index

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12207>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:29:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 15:29:05 +0000
Subject: [issue8933] Invalid detection of metadata version
In-Reply-To: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>
Message-ID: <1308065345.8.0.868505253531.issue8933@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ll look into this shortly.

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8933>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:33:03 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 14 Jun 2011 15:33:03 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1308065583.88.0.429447792463.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Just had a successful XP buildbot run: http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.2/builds/304

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:35:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 15:35:46 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1308065746.55.0.559828457245.issue1222585@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
type: compile error -> feature request
versions: +Python 3.3 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:41:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 15:41:18 +0000
Subject: [issue11218] pattern=None when following documentation for load_tests
	and unittest.main()
In-Reply-To: <1297758807.39.0.713611114484.issue11218@psf.upfronthosting.co.za>
Message-ID: <1308066078.11.0.653782673043.issue11218@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: docs at python -> 
components:  -Documentation
nosy: +eric.araujo, ezio.melotti, michael.foord -docs at python
stage:  -> test needed
type: feature request -> behavior
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11218>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:42:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 15:42:53 +0000
Subject: [issue10530] distutils2 should allow the installing of python files
	with invalid syntax
In-Reply-To: <1290698215.47.0.78092585837.issue10530@psf.upfronthosting.co.za>
Message-ID: <1308066173.08.0.977178862454.issue10530@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> A --strict option could be provided to allow these to remain an error.

Or a config option could let you list the files that should not be byte-compiled.

----------
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10530>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:43:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 15:43:29 +0000
Subject: [issue10514] configure does not create accurate Makefile on AIX
In-Reply-To: <1290519521.61.0.0855233461913.issue10514@psf.upfronthosting.co.za>
Message-ID: <1308066209.29.0.845003581629.issue10514@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: configure does not create accurate Makefile -> configure does not create accurate Makefile on AIX

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10514>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:46:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 15:46:03 +0000
Subject: [issue10457] "Related help topics" shown outside pager
In-Reply-To: <1290174817.07.0.690141680958.issue10457@psf.upfronthosting.co.za>
Message-ID: <1308066363.28.0.437284373449.issue10457@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your message.  There was already a report for this bug, so I?m closing this one.

----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> pydoc.Helper.help() ignores input/output init parameters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10457>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:47:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 15:47:27 +0000
Subject: [issue8255] Packaging step-by-step tutorial
In-Reply-To: <1269787637.04.0.463586986817.issue8255@psf.upfronthosting.co.za>
Message-ID: <1308066447.76.0.794445997659.issue8255@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think the official documentation is less opinionated than the Hitchhiker?s Guide.

----------
title: step-by-step tutorial -> Packaging step-by-step tutorial
versions: +Python 3.3 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8255>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:48:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 15:48:05 +0000
Subject: [issue9741] msgfmt.py generates invalid mo because msgfmt.make() does
	not clear dictionary
In-Reply-To: <1283437902.68.0.344684434437.issue9741@psf.upfronthosting.co.za>
Message-ID: <1308066485.83.0.327511613026.issue9741@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report and patch.  Can you write a test?

----------
nosy: +eric.araujo
stage: patch review -> test needed
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9741>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:48:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 15:48:58 +0000
Subject: [issue8534] multiprocessing not working from egg
In-Reply-To: <1272279135.33.0.722115657871.issue8534@psf.upfronthosting.co.za>
Message-ID: <1308066538.47.0.524768285327.issue8534@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m not sure this belongs on the Python tracker.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8534>
_______________________________________

From report at bugs.python.org  Tue Jun 14 17:58:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 15:58:35 +0000
Subject: [issue11493] Add python.exe-gdb.py to .hgignore
In-Reply-To: <1300088302.91.0.551103844028.issue11493@psf.upfronthosting.co.za>
Message-ID: <1308067115.66.0.422608400178.issue11493@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

What is python.exe-gdb.py?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11493>
_______________________________________

From report at bugs.python.org  Tue Jun 14 18:02:57 2011
From: report at bugs.python.org (Michael Foord)
Date: Tue, 14 Jun 2011 16:02:57 +0000
Subject: [issue10530] distutils2 should allow the installing of python files
	with invalid syntax
In-Reply-To: <1290698215.47.0.78092585837.issue10530@psf.upfronthosting.co.za>
Message-ID: <1308067377.52.0.392258689026.issue10530@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Config options are for when developers can't make decisions. Given that there are valid use cases please just allow it. A --strict option is fine... (but no-one will use it I suspect)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10530>
_______________________________________

From report at bugs.python.org  Tue Jun 14 18:03:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 16:03:12 +0000
Subject: [issue5575] Add env vars for controlling building sqlite,
	hashlib and ssl
In-Reply-To: <1238101680.27.0.350099709898.issue5575@psf.upfronthosting.co.za>
Message-ID: <1308067392.34.0.586024085755.issue5575@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5575>
_______________________________________

From report at bugs.python.org  Tue Jun 14 18:03:37 2011
From: report at bugs.python.org (Stephen White)
Date: Tue, 14 Jun 2011 16:03:37 +0000
Subject: [issue762963] timemodule.c: Python loses current timezone
Message-ID: <1308067417.39.0.618178450839.issue762963@psf.upfronthosting.co.za>


Stephen White <stephen-python.org at randomstuff.org.uk> added the comment:

The patch, issue762963.diff, is broken.  It is calling mktime on a struct tm that is initialized to zeros.  This means that it should be filling in the missing fields based on their correct values for the date 1st Jan 1900, which is incorrect behaviour as the whole method should be choosing appropriate values based on the date provided by the user.

However in practice this call to mktime is effectively a no-op on 32bit systems.  The reason for this is:

The mktime(p) call is at the top of the method, straight after the memset(p, '\0', ...) call.  This means p->tm_year is zero.  According to the definition of struct tm a zero in the year field means 1900.

On a 32bit system the earliest date handled by libc is 2**31 seconds before the Epoch (1st Jan 1970);
>>> time.strftime("%Y-%m-%d %H:%M:%S %Z", time.localtime(-2**31))'1901-12-13 20:45:52 GMT'

So dates in the year 1900 cannot be handled by libc, and in this situation the mktime(p) call makes no attempt to normalise the provided data (or fill in missing values).

The situation is different on 64bit systems.  Here there is no problem with a much wider range of dates.  This means that dates during 1900 *are* handled by libc, and so it does attempt to normalise the data and fill in missing values.

For most of the fields in the structure whether or not mktime fills in or alters their value is of little consequence, as they're immediately overwritten by the call to PyArg_Parse.  However the contents of the tm_gmtoff & tm_zone fields are not overwritten.

If the mktime call does nothing (as on a 32bit system) then tm_zone remains NULL throughout.

If the mktime call does fill in missing values (as on 64bit systems) then tm_zone is set to the appropriate timezone for the zero time (the beginning of the year 1900).  In our case this is always "GMT", because the beginning of the year is in winter (when we use GMT).

If tm_zone is set when the structure is passed into strftime then it is honoured.  So if it has been set by mktime to be GMT then strftime will output GMT, regardless of the correct timezone string for the actual time provided.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue762963>
_______________________________________

From report at bugs.python.org  Tue Jun 14 18:03:41 2011
From: report at bugs.python.org (Michael Foord)
Date: Tue, 14 Jun 2011 16:03:41 +0000
Subject: [issue11218] pattern=None when following documentation for load_tests
	and unittest.main()
In-Reply-To: <1297758807.39.0.713611114484.issue11218@psf.upfronthosting.co.za>
Message-ID: <1308067421.29.0.223444035485.issue11218@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
assignee:  -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11218>
_______________________________________

From report at bugs.python.org  Tue Jun 14 18:03:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 16:03:49 +0000
Subject: [issue7594] shlex refactoring
In-Reply-To: <1262074061.97.0.349318449782.issue7594@psf.upfronthosting.co.za>
Message-ID: <1308067429.39.0.0986392414496.issue7594@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7594>
_______________________________________

From report at bugs.python.org  Tue Jun 14 18:08:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Jun 2011 16:08:16 +0000
Subject: [issue10530] distutils2 should allow the installing of python files
	with invalid syntax
In-Reply-To: <1290698215.47.0.78092585837.issue10530@psf.upfronthosting.co.za>
Message-ID: <1308067696.74.0.943809034233.issue10530@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Config options are for when developers can't make decisions.
I don?t understand.  In packaging, a config file is central, as it contains the whole metadata, manifest and command options.

> Given that there are valid use cases please just allow it.
If this was not clear: I agree with the feature request.  Or maybe you meant allowing it by default?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10530>
_______________________________________

From report at bugs.python.org  Tue Jun 14 18:12:04 2011
From: report at bugs.python.org (Michael Foord)
Date: Tue, 14 Jun 2011 16:12:04 +0000
Subject: [issue10530] distutils2 should allow the installing of python files
	with invalid syntax
In-Reply-To: <1290698215.47.0.78092585837.issue10530@psf.upfronthosting.co.za>
Message-ID: <1308067924.8.0.777428507291.issue10530@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Yes, allowing it by default. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10530>
_______________________________________

From report at bugs.python.org  Tue Jun 14 18:28:23 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 14 Jun 2011 16:28:23 +0000
Subject: [issue1612012] builtin compile() doc needs PyCF_DONT_IMPLY_DEDENT
Message-ID: <1308068903.5.0.0954436841269.issue1612012@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Is this something that would actually be useful to someone using compile()?

See #12207 also

----------
nosy: +terry.reedy
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1612012>
_______________________________________

From report at bugs.python.org  Tue Jun 14 18:35:53 2011
From: report at bugs.python.org (Carmine Paolino)
Date: Tue, 14 Jun 2011 16:35:53 +0000
Subject: [issue12332] Float division
In-Reply-To: <1308058763.8.0.977949116716.issue12332@psf.upfronthosting.co.za>
Message-ID: <1308069353.22.0.10629578969.issue12332@psf.upfronthosting.co.za>


Carmine Paolino <paolino.carmine at alice.it> added the comment:

Thank you for your help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12332>
_______________________________________

From report at bugs.python.org  Tue Jun 14 20:14:37 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 14 Jun 2011 18:14:37 +0000
Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in
	select()"
In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za>
Message-ID: <1308075277.56.0.324263011515.issue10527@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/issue10527>
_______________________________________

From report at bugs.python.org  Tue Jun 14 20:17:32 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 14 Jun 2011 18:17:32 +0000
Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in
	select()"
In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za>
Message-ID: <1308075452.72.0.689383609229.issue10527@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

The analogous code within Modules/selectmodule.c uses
  #ifdef HAVE_POLL
to guard the poll-using code, to support non-Windows platforms that don't have "poll".

Presumably a patch for this should do the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10527>
_______________________________________

From report at bugs.python.org  Tue Jun 14 20:20:33 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 14 Jun 2011 18:20:33 +0000
Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in
	select()"
In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za>
Message-ID: <1308075633.92.0.802720671033.issue10527@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Also, I see that Modules/selectmodule.c has some painful-looking workarounds involving "HAVE_BROKEN_POLL", which presumably would also be applicable here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10527>
_______________________________________

From report at bugs.python.org  Tue Jun 14 22:21:05 2011
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 14 Jun 2011 20:21:05 +0000
Subject: [issue6717] Some problem with recursion handling
In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>
Message-ID: <1308082865.66.0.630881984286.issue6717@psf.upfronthosting.co.za>


Dino Viehland <dinov at microsoft.com> added the comment:

I ran into a similar issue and believe I have a simpler repro.  I think the issue here might be that when you take a stack overflow inside of a sys.settrace handler that you can then later violate the stack depth.  The attached test.py has no dependencies and crashes 3.x but works on 2.x.

----------
nosy: +dino.viehland
Added file: http://bugs.python.org/file22365/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6717>
_______________________________________

From report at bugs.python.org  Tue Jun 14 22:57:31 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 14 Jun 2011 20:57:31 +0000
Subject: [issue12335] pysetup create will clobber an existing setup.cfg
In-Reply-To: <1308085051.29.0.289061158176.issue12335@psf.upfronthosting.co.za>
Message-ID: <1308085051.29.0.289061158176.issue12335@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

I have both a setup.py and a setup.cfg in my package.  I wanted to use `pysetup create` to add the new packaging stanzas to my setup.cfg, but instead, pysetup clobbered everything.  I think it should instead append (or prepend) the new stuff to the existing file.

----------
components: Library (Lib)
messages: 138348
nosy: barry
priority: normal
severity: normal
status: open
title: pysetup create will clobber an existing setup.cfg
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12335>
_______________________________________

From report at bugs.python.org  Tue Jun 14 23:02:56 2011
From: report at bugs.python.org (Hans Peter de Koning)
Date: Tue, 14 Jun 2011 21:02:56 +0000
Subject: [issue11113] html.entities mapping dicts need updating?
In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>
Message-ID: <1308085376.61.0.205164393103.issue11113@psf.upfronthosting.co.za>


Hans Peter de Koning <hpdk at xs4all.nl> added the comment:

The reason I raised #12329 was that the v2.7.1 documentation in
http://docs.python.org/library/htmllib.html#module-htmlentitydefs
says:
"... The definition provided here contains all the entities defined by XHTML 1.0 ..."
The only diff between the 252 HTML 4.01 and 253 XHTML 1.0 entities is "apos". See http://www.w3.org/TR/html401/sgml/entities.html and http://www.w3.org/TR/xhtml1/dtds.html .

----------
nosy: +hp.dekoning

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11113>
_______________________________________

From report at bugs.python.org  Tue Jun 14 23:09:05 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 14 Jun 2011 21:09:05 +0000
Subject: [issue12335] pysetup create will clobber an existing setup.cfg
In-Reply-To: <1308085051.29.0.289061158176.issue12335@psf.upfronthosting.co.za>
Message-ID: <1308085745.95.0.0269681811604.issue12335@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/issue12335>
_______________________________________

From report at bugs.python.org  Tue Jun 14 23:13:22 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 14 Jun 2011 21:13:22 +0000
Subject: [issue12313] make install misses packaging module
In-Reply-To: <1307722082.95.0.13819638115.issue12313@psf.upfronthosting.co.za>
Message-ID: <1308086002.16.0.991982532594.issue12313@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/issue12313>
_______________________________________

From report at bugs.python.org  Tue Jun 14 23:26:29 2011
From: report at bugs.python.org (Torsten Landschoff)
Date: Tue, 14 Jun 2011 21:26:29 +0000
Subject: [issue11797] 2to3 does not correct "reload"
In-Reply-To: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>
Message-ID: <1308086789.97.0.329732485724.issue11797@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

The other use case I see is to reload a module during debugging after changing the code. This is especially useful for big GUI applications.

----------
nosy: +torsten

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11797>
_______________________________________

From report at bugs.python.org  Tue Jun 14 23:28:19 2011
From: report at bugs.python.org (Hans Peter de Koning)
Date: Tue, 14 Jun 2011 21:28:19 +0000
Subject: [issue11113] html.entities mapping dicts need updating?
In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>
Message-ID: <1308086899.43.0.470685374171.issue11113@psf.upfronthosting.co.za>


Hans Peter de Koning <hpdk at xs4all.nl> added the comment:

BTW, the HTMLParser module (as well as html.parser in 3.x) does claim to parse both HTML and XHTML, see http://docs.python.org/library/htmlparser.html#module-HTMLParser .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11113>
_______________________________________

From report at bugs.python.org  Tue Jun 14 23:42:17 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 14 Jun 2011 21:42:17 +0000
Subject: [issue12313] make install misses packaging module
In-Reply-To: <1307722082.95.0.13819638115.issue12313@psf.upfronthosting.co.za>
Message-ID: <1308087737.53.0.718321158491.issue12313@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Nice to see my search didn't find this bug. ;)

I already committed a change to install packaging, but you may want to revert that and commit the patch in this issue.  I'll leave that for you to decide!

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12313>
_______________________________________

From report at bugs.python.org  Tue Jun 14 23:58:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Jun 2011 21:58:19 +0000
Subject: [issue12336] tkinter.test.test_ttk.test_widgets.test_select() failure
	on FreeBSD 6.4 3.x
In-Reply-To: <1308088699.26.0.99920721974.issue12336@psf.upfronthosting.co.za>
Message-ID: <1308088699.26.0.99920721974.issue12336@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test test_ttk_guionly failed -- Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/tkinter/test/test_ttk/test_widgets.py", line 674, in test_select
    self.assertTrue(success)
AssertionError: [] is not true

http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/1579/steps/test/logs/stdio

This buildbot is very slow.

See also #11925 and #10736.

----------
components: Tests, Tkinter
keywords: buildbot
messages: 138353
nosy: haypo
priority: normal
severity: normal
status: open
title: tkinter.test.test_ttk.test_widgets.test_select() failure on FreeBSD 6.4 3.x
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12336>
_______________________________________

From report at bugs.python.org  Wed Jun 15 00:05:50 2011
From: report at bugs.python.org (Paul Boddie)
Date: Tue, 14 Jun 2011 22:05:50 +0000
Subject: [issue762963] timemodule.c: Python loses current timezone
Message-ID: <1308089150.15.0.554641118462.issue762963@psf.upfronthosting.co.za>


Paul Boddie <paul at boddie.org.uk> added the comment:

I don't understand how this bug and its patches are still active. It's difficult for me to remember what I was doing in early 2007 when I started working on issue #1667546, but I can well imagine that it was in response to this and a number of related bugs. Looking at #1667546, it's clear that the work required to handle time zones is not at all as trivial as the patches attached to this issue appear to be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue762963>
_______________________________________

From report at bugs.python.org  Wed Jun 15 00:40:27 2011
From: report at bugs.python.org (sbt)
Date: Tue, 14 Jun 2011 22:40:27 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>
Message-ID: <1308091227.33.0.329224594915.issue12328@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> Also, what is the rationale for the following change:
> 
> -            elif timeout == 0.0:
> +            elif timeout == 0.0 and nleft != 0:
>                  return False

If PeekNamedPipe() returns (navail, nleft) there are 3 cases:

1) navail > 0: just return True
2) navail = nleft = 0: either pipe is empty or next message is empty
   so fall through to slow path to find out which.
3) navail = 0, nleft > 0: a non-empty message is coming, but nothing 
   is available yet.

The check is a shortcut for case 3, although it probably never 
occurs.  I've removed that check in the new patch, and added the 
unit tests to test_multiprocessing.

> There is infrastructure in _multiprocessing to handle Ctrl-C. Look 
> for "sigint_event" in Modules/_multiprocessing/*. This could be 
> the topic of a separate issue and patch.

I will look in to it.

----------
Added file: http://bugs.python.org/file22366/pipe_poll_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Wed Jun 15 00:50:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 14 Jun 2011 22:50:27 +0000
Subject: [issue11113] html.entities mapping dicts need updating?
In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>
Message-ID: <1308091827.7.0.180887244105.issue11113@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/issue11113>
_______________________________________

From report at bugs.python.org  Wed Jun 15 00:57:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 14 Jun 2011 22:57:11 +0000
Subject: [issue1669539] Fix bug in os.path.join
Message-ID: <1308092231.31.0.923279138906.issue1669539@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy:  -jongfoster

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1669539>
_______________________________________

From report at bugs.python.org  Wed Jun 15 06:59:53 2011
From: report at bugs.python.org (Fan Decheng)
Date: Wed, 15 Jun 2011 04:59:53 +0000
Subject: [issue12337] Need real TextIOWrapper for stdin/stdout
In-Reply-To: <1308113993.07.0.688068575261.issue12337@psf.upfronthosting.co.za>
Message-ID: <1308113993.07.0.688068575261.issue12337@psf.upfronthosting.co.za>


New submission from Fan Decheng <fandecheng at gmail.com>:

Since "-u" is made default and binary stdio implemented in 3.2, many of my scripts cannot run directly in Python 3.2, because they expect "\n" from stdin, but on Windows "\r\n" is got.

Since that binary stdio being default is necessary for features like CGI, what I am expecting is to get a real TextIOWrapper for stdin, so that I can still use my old code. Besides, type(sys.stdio) should no longer say TextIOWrapper, because TextIOWrapper implies the conversion from "\r\n" to "\n".

Steps to reproduce:
In Python 3.2:
>>> import sys
>>> type(sys.stdin)
<class '_io.TextIOWrapper'>
>>> sys.stdin.readline()
a
'a\r\n'
>>> type(sys.stdout)
<class '_io.TextIOWrapper'>

Expected result:
There should be some form of text support, such as textstream(sys.stdin).readline(). Also type(sys.stdin) should not say something like "TextIOWrapper". Same for sys.stdout.

----------
components: IO
messages: 138356
nosy: r_mosaic
priority: normal
severity: normal
status: open
title: Need real TextIOWrapper for stdin/stdout
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12337>
_______________________________________

From report at bugs.python.org  Wed Jun 15 09:39:49 2011
From: report at bugs.python.org (harobed)
Date: Wed, 15 Jun 2011 07:39:49 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
	"chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1308123589.94.0.917967662898.issue12319@psf.upfronthosting.co.za>


harobed <stephane at harobed.org> added the comment:

> Now I'm confused. Per the HTTP specification, GET requests don't have
a body, so "Transfer-Encoding: chunked" doesn't apply to them.

> Are you sure you don't confuse with the response that the server
sends? In responses, "Transfer-Encoding: chunked" is very common.

Sorry, yes GET requests have "Transfer-Encoding: chunked" in server response.
PUT requests can send body data in transfer-encoding chunked mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12319>
_______________________________________

From report at bugs.python.org  Wed Jun 15 09:42:56 2011
From: report at bugs.python.org (harobed)
Date: Wed, 15 Jun 2011 07:42:56 +0000
Subject: [issue12327] in HTTPConnection the are len(body) and TypeError catch
	exception to detect if body is file like object,
	this hack do work with StringIO object
In-Reply-To: <1307987409.37.0.379147237937.issue12327@psf.upfronthosting.co.za>
Message-ID: <1308123776.71.0.525382200898.issue12327@psf.upfronthosting.co.za>


harobed <stephane at harobed.org> added the comment:

> But if the len information is available, why not return it?

I use HTTPConnection to simulate Apple Finder WebDAV client.
When this WebDAV client do PUT request, it transmit data in chunked encoding mode and not set Content-Length HTTP field.

Do you understand my context ?

Regards,
Stephane

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12327>
_______________________________________

From report at bugs.python.org  Wed Jun 15 10:14:19 2011
From: report at bugs.python.org (Jelte)
Date: Wed, 15 Jun 2011 08:14:19 +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: <1308125659.32.0.0593750645292.issue11147@psf.upfronthosting.co.za>


Changes by Jelte <python at tjeb.nl>:


----------
nosy: +Tjebbe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11147>
_______________________________________

From report at bugs.python.org  Wed Jun 15 10:17:44 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 15 Jun 2011 08:17:44 +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: <1308125864.11.0.790640566492.issue11934@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

FWIW, I recall that I built 2.7 a while back with --prefix=/home/user/something and it also failed to find zlib. Due to lack of time, I didn't debug it very deeply then, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11934>
_______________________________________

From report at bugs.python.org  Wed Jun 15 12:11:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Jun 2011 10:11:13 +0000
Subject: [issue12337] Need real TextIOWrapper for stdin/stdout
In-Reply-To: <1308113993.07.0.688068575261.issue12337@psf.upfronthosting.co.za>
Message-ID: <1308132673.43.0.822518559468.issue12337@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I can't reproduce. Victor?


Z:\default>PCbuild\amd64\python_d.exe
Python 3.3a0 (default, Jun  8 2011, 17:49:13) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdin.readline()
a
'a\n'
>>> ^Z

Z:\default>PCbuild\amd64\python_d.exe -u
Python 3.3a0 (default, Jun  8 2011, 17:49:13) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdin.readline()
a
'a\n'

----------
nosy: +amaury.forgeotdarc, haypo, pitrou
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12337>
_______________________________________

From report at bugs.python.org  Wed Jun 15 13:55:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jun 2011 11:55:55 +0000
Subject: [issue12337] Need real TextIOWrapper for stdin/stdout
In-Reply-To: <1308113993.07.0.688068575261.issue12337@psf.upfronthosting.co.za>
Message-ID: <1308138955.36.0.708494988926.issue12337@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think that this issue is a duplicate of the issue #11272: Python 3.2.1 has been released recently and contains the fix. Can you try this version Fan?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12337>
_______________________________________

From report at bugs.python.org  Wed Jun 15 13:56:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jun 2011 11:56:36 +0000
Subject: [issue12337] Need real TextIOWrapper for stdin/stdout
In-Reply-To: <1308113993.07.0.688068575261.issue12337@psf.upfronthosting.co.za>
Message-ID: <1308138996.84.0.332487993389.issue12337@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Note: Python 3.2 has another regression related to the Windows console (issue #11395), bug fixed in 3.2.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12337>
_______________________________________

From report at bugs.python.org  Wed Jun 15 15:17:18 2011
From: report at bugs.python.org (sbt)
Date: Wed, 15 Jun 2011 13:17:18 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>
Message-ID: <1308143838.76.0.17999098178.issue12328@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

pipe_interruptible.patch is a patch to support to making poll() interruptible.  It applies on top of pipe_poll_2.patch.

I am not sure what the guarantees are for when KeyboardInterrupt will be raised.

I would have done it a bit differently if I knew a good way to test whether the current thread is the main one.  Maybe there should be something like PyThread_is_main() and/or threading.ismain().

----------
Added file: http://bugs.python.org/file22367/pipe_interruptible.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Wed Jun 15 15:24:28 2011
From: report at bugs.python.org (sbt)
Date: Wed, 15 Jun 2011 13:24:28 +0000
Subject: [issue12338] multiprocessing.util._eintr_retry doen't recalculate
	timeouts
In-Reply-To: <1308144268.86.0.218604754177.issue12338@psf.upfronthosting.co.za>
Message-ID: <1308144268.86.0.218604754177.issue12338@psf.upfronthosting.co.za>


New submission from sbt <shibturn at gmail.com>:

multiprocessing.util._eintr_retry is only used to wrap select.select, but it fails to recalculate timeouts.

Also, it will never retry the function it wraps because of a missing "import errno".

I think it would be better to just implement the retrying version of select directly.

----------
messages: 138364
nosy: sbt
priority: normal
severity: normal
status: open
title: multiprocessing.util._eintr_retry doen't recalculate timeouts

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12338>
_______________________________________

From report at bugs.python.org  Wed Jun 15 15:36:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Jun 2011 13:36:05 +0000
Subject: [issue12313] make install misses packaging module
In-Reply-To: <1307722082.95.0.13819638115.issue12313@psf.upfronthosting.co.za>
Message-ID: <1308144965.0.0.527485032817.issue12313@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Nice to see my search didn't find this bug. ;)
Do you remember what search terms you tried?

> I already committed a change to install packaging, but you may want to
> revert that and commit the patch in this issue.
I honestly don?t know.  Do we have a policy about using intermediary variables (like XMLLIBSUBDIRS) or not?  Can we assume find(1) exists on the system and use it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12313>
_______________________________________

From report at bugs.python.org  Wed Jun 15 15:38:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Jun 2011 13:38:38 +0000
Subject: [issue11113] html.entities mapping dicts need updating?
In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>
Message-ID: <1308145118.84.0.252845808014.issue11113@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ah, this changes the situation.  I suppose it?s too late to stop pretending that HTML and XHTML are nearly the same thing (IOW change the doc), so apos needs to be defined for XHTML.

IMO, we need a way to have the right entity references for HTML 4.01, XHTML 1.0 and HTML5, not put them all in one mapping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11113>
_______________________________________

From report at bugs.python.org  Wed Jun 15 15:40:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Jun 2011 13:40:36 +0000
Subject: [issue7969] shutil.copytree error handling non-standard and partially
	broken
In-Reply-To: <1266617058.24.0.24785922897.issue7969@psf.upfronthosting.co.za>
Message-ID: <1308145236.17.0.160955984021.issue7969@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also http://mail.python.org/pipermail/docs/2010-August/001207.html for a similar report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7969>
_______________________________________

From report at bugs.python.org  Wed Jun 15 15:41:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Jun 2011 13:41:38 +0000
Subject: [issue12327] in HTTPConnection the are len(body) and TypeError catch
	exception to detect if body is file like object,
	this hack do work with StringIO object
In-Reply-To: <1307987409.37.0.379147237937.issue12327@psf.upfronthosting.co.za>
Message-ID: <1308145298.43.0.972334617057.issue12327@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The code you are suggesting patching is trying its best to return a length.  If that code needs to be fixed to not throw an error when confronted with a StringIO, then it should do its best to return a length.  Your original message on the ticket did not mention chunked encoding, and indeed that appears to be correct.  This bug doesn't appear, from what you have written and what I see in the 3.x code, to have anything to do with chunked encoding.

----------
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12327>
_______________________________________

From report at bugs.python.org  Wed Jun 15 15:42:01 2011
From: report at bugs.python.org (Piotr Czachur)
Date: Wed, 15 Jun 2011 13:42:01 +0000
Subject: [issue12339] logging.Formatter.format() assumes exception to support
	str() method which is not true for many libraries.
In-Reply-To: <1308145321.11.0.0545021570949.issue12339@psf.upfronthosting.co.za>
Message-ID: <1308145321.11.0.0545021570949.issue12339@psf.upfronthosting.co.za>


New submission from Piotr Czachur <zimnyx at gmail.com>:

If I want my application to be bullet-proof against external libraries that can (and often do) raise Exception(u'nonascii'), I cannot use python's logger.exception() directly, as it will end up with UnicodeDecodeError. 

The reason is hidden in Formatter.format() which does:
    s = self._fmt % record.__dict__

One can use his own formatter that can handle UnicodeDecodeError, but many users are quite unaware of such issue and it would be great if Python can handle it by itself.


Here is a simple case.

>>> e = Exception(u'?')
>>> logging.basicConfig()
>>> logging.getLogger('general').exception(u'?')
?
None
>>> logging.getLogger('general').exception(e)
Traceback (most recent call last):
  File "/usr/lib/python2.7/logging/__init__.py", line 842, in emit
    msg = self.format(record)
  File "/usr/lib/python2.7/logging/__init__.py", line 719, in format
    return fmt.format(record)
  File "/usr/lib/python2.7/logging/__init__.py", line 467, in format
    s = self._fmt % record.__dict__
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0105' in position 0: ordinal not in range(128)
Logged from file <stdin>, line 1
>>> unicode(e)
u'\u0105'
>>> str(e)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0105' in position 0: ordinal not in range(128)
>>>

----------
components: Library (Lib)
messages: 138369
nosy: Piotr.Czachur
priority: normal
severity: normal
status: open
title: logging.Formatter.format() assumes exception to support str() method which is not true for many libraries.
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12339>
_______________________________________

From report at bugs.python.org  Wed Jun 15 15:43:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Jun 2011 13:43:20 +0000
Subject: [issue12339] logging.Formatter.format() assumes exception to support
	str() method which is not true for many libraries.
In-Reply-To: <1308145321.11.0.0545021570949.issue12339@psf.upfronthosting.co.za>
Message-ID: <1308145400.2.0.574251020513.issue12339@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12339>
_______________________________________

From report at bugs.python.org  Wed Jun 15 15:45:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Jun 2011 13:45:34 +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: <1308145534.87.0.958101410164.issue11934@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I normally build using --prefix, often with --prefix=/dev/null, and I can't recall any version not building zlib.  Of course, I don't uncomment the zlib entry in Modules/Setup.

As far as I can see the zlib entry is unique in Setup in using prefix, so it probably is a bug (or, rather, a holdover from when there were various issues with the platform zlib).

----------
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11934>
_______________________________________

From report at bugs.python.org  Wed Jun 15 15:47:29 2011
From: report at bugs.python.org (Timothy Lee)
Date: Wed, 15 Jun 2011 13:47:29 +0000
Subject: [issue9741] msgfmt.py generates invalid mo because msgfmt.make() does
	not clear dictionary
In-Reply-To: <1283437902.68.0.344684434437.issue9741@psf.upfronthosting.co.za>
Message-ID: <1308145649.8.0.190024189298.issue9741@psf.upfronthosting.co.za>


Changes by Timothy Lee <timothy.ty.lee at gmail.com>:


Added file: http://bugs.python.org/file22368/test_msgfmt.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9741>
_______________________________________

From report at bugs.python.org  Wed Jun 15 15:49:00 2011
From: report at bugs.python.org (Timothy Lee)
Date: Wed, 15 Jun 2011 13:49:00 +0000
Subject: [issue9741] msgfmt.py generates invalid mo because msgfmt.make() does
	not clear dictionary
In-Reply-To: <1283437902.68.0.344684434437.issue9741@psf.upfronthosting.co.za>
Message-ID: <1308145740.19.0.370381751186.issue9741@psf.upfronthosting.co.za>


Changes by Timothy Lee <timothy.ty.lee at gmail.com>:


Added file: http://bugs.python.org/file22369/test1.po

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9741>
_______________________________________

From report at bugs.python.org  Wed Jun 15 15:49:28 2011
From: report at bugs.python.org (Timothy Lee)
Date: Wed, 15 Jun 2011 13:49:28 +0000
Subject: [issue9741] msgfmt.py generates invalid mo because msgfmt.make() does
	not clear dictionary
In-Reply-To: <1283437902.68.0.344684434437.issue9741@psf.upfronthosting.co.za>
Message-ID: <1308145768.7.0.169072668125.issue9741@psf.upfronthosting.co.za>


Changes by Timothy Lee <timothy.ty.lee at gmail.com>:


Added file: http://bugs.python.org/file22370/test2.po

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9741>
_______________________________________

From report at bugs.python.org  Wed Jun 15 15:59:45 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 15 Jun 2011 13:59:45 +0000
Subject: [issue12339] logging.Formatter.format() assumes exception to support
	str() method which is not true for many libraries.
In-Reply-To: <1308145321.11.0.0545021570949.issue12339@psf.upfronthosting.co.za>
Message-ID: <1308146385.41.0.348707147701.issue12339@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This is happening because if you pass an object instead of a string as the first argument in a logging call, it's treated as a message object whose __str__() will be called to get the actual message when it's needed, as documented here:

http://docs.python.org/howto/logging.html#arbitrary-object-messages

If, instead, you do it like this:

# coding: utf-8
import logging

logging.basicConfig()
try:
    raise Exception(u'?')
except Exception:
    logging.getLogger('general').exception(u'An error occurred')

you get

ERROR:general:An error occurred
Traceback (most recent call last):
  File "bug_12339.py", line 6, in <module>
    raise Exception(u'?')
Exception: \u0105

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12339>
_______________________________________

From report at bugs.python.org  Wed Jun 15 16:00:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Jun 2011 14:00:31 +0000
Subject: [issue9741] msgfmt.py generates invalid mo because msgfmt.make() does
	not clear dictionary
In-Reply-To: <1283437902.68.0.344684434437.issue9741@psf.upfronthosting.co.za>
Message-ID: <1308146431.58.0.914542400265.issue9741@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks!  In my latest message, I had forgotten that msgfmt was in Tools, not in the standard library, and as such has no automated regression tests.  Features get added and bugs get fixed after manual testing only, so I will commit your patch (modulo the unneeded global statement) without tests (but after manual testing) unless someone objects.

----------
assignee:  -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9741>
_______________________________________

From report at bugs.python.org  Wed Jun 15 16:04:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Jun 2011 14:04:15 +0000
Subject: [issue12335] pysetup create will clobber an existing setup.cfg
In-Reply-To: <1308085051.29.0.289061158176.issue12335@psf.upfronthosting.co.za>
Message-ID: <1308146655.52.0.69527014995.issue12335@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Well, create is not update :)  In its current form, create will save an existing setup.cfg as setup.cfg.old and generate a new one.  The human operator will then have to merge both files if necessary.  Automatically merging the old file into the new one would raise issues with respect to comments, whitespace and all that in Pythons < 3.2.

The doc and help messages are probably unclear about that.

----------
assignee:  -> tarek
components: +Distutils2 -Library (Lib)
nosy: +alexis, eric.araujo, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12335>
_______________________________________

From report at bugs.python.org  Wed Jun 15 16:23:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Jun 2011 14:23:34 +0000
Subject: [issue9674] make install DESTDIR=/home/blah fails when the prefix
	specified is /
In-Reply-To: <1282677588.85.0.771807305266.issue9674@psf.upfronthosting.co.za>
Message-ID: <1308147814.02.0.0143023347103.issue9674@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks.  Have you run the test suite to make sure this doesn?t add bugs?

----------
assignee: tarek -> eric.araujo
components:  -Build, Installation, Library (Lib)
stage:  -> test needed
type: compile error -> behavior
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9674>
_______________________________________

From report at bugs.python.org  Wed Jun 15 16:34:12 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 15 Jun 2011 14:34:12 +0000
Subject: [issue12335] pysetup create will clobber an existing setup.cfg
In-Reply-To: <1308146655.52.0.69527014995.issue12335@psf.upfronthosting.co.za>
Message-ID: <20110615103407.3c6e2d5a@neurotica.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Jun 15, 2011, at 02:04 PM, ?ric Araujo wrote:

>Well, create is not update :) In its current form, create will save an
>existing setup.cfg as setup.cfg.old and generate a new one.  The human
>operator will then have to merge both files if necessary.  Automatically
>merging the old file into the new one would raise issues with respect to
>comments, whitespace and all that in Pythons < 3.2.
>
>The doc and help messages are probably unclear about that.

I missed the setup.cfg.old.  I think that's fine.  Probably `create` should
print a message that it moved setup.cfg to setup.cfg.old.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12335>
_______________________________________

From report at bugs.python.org  Wed Jun 15 16:36:25 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 15 Jun 2011 14:36:25 +0000
Subject: [issue12335] pysetup create will clobber an existing setup.cfg
In-Reply-To: <1308085051.29.0.289061158176.issue12335@psf.upfronthosting.co.za>
Message-ID: <1308148585.04.0.918839187362.issue12335@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I find this behavior a bit awkward. Maybe we should ask first if it's ok to create a new setup.cfg and rename the old one, *before* doing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12335>
_______________________________________

From report at bugs.python.org  Wed Jun 15 16:40:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Jun 2011 14:40:58 +0000
Subject: [issue12335] pysetup create: ask before moving an existing setup.cfg
In-Reply-To: <1308085051.29.0.289061158176.issue12335@psf.upfronthosting.co.za>
Message-ID: <1308148858.23.0.340073896053.issue12335@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Maybe we should ask first if it's ok to create a new setup.cfg and
> rename the old one, *before* doing it.

Agreed, if ?yes? is the default answer.

----------
title: pysetup create will clobber an existing setup.cfg -> pysetup create: ask before moving an existing setup.cfg
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12335>
_______________________________________

From report at bugs.python.org  Wed Jun 15 16:42:04 2011
From: report at bugs.python.org (Michael Foord)
Date: Wed, 15 Jun 2011 14:42:04 +0000
Subject: [issue12314] regrtest checks (os.environ, sys.path,
	etc.) are hard to use
In-Reply-To: <1307722749.85.0.48203387339.issue12314@psf.upfronthosting.co.za>
Message-ID: <1308148924.29.0.253275686815.issue12314@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I don't think this is something that belongs in unittest - it's not something particularly useful (or at least particularly requested) outside of the python test suite. No reason that a WatchfulTestRunner couldn't live in regrtest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12314>
_______________________________________

From report at bugs.python.org  Wed Jun 15 16:47:07 2011
From: report at bugs.python.org (ysj.ray)
Date: Wed, 15 Jun 2011 14:47:07 +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: <1308149227.28.0.955215620958.issue11934@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

Isn?t zlib built by setup.py anyway?


If can be build by Modules/Setup first as a builtin module, then the setup.py woun't build it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11934>
_______________________________________

From report at bugs.python.org  Wed Jun 15 17:07:05 2011
From: report at bugs.python.org (Peter Waller)
Date: Wed, 15 Jun 2011 15:07:05 +0000
Subject: [issue1711800] SequenceMatcher bug with insert/delete block after
	"replace"
Message-ID: <1308150425.99.0.498763740522.issue1711800@psf.upfronthosting.co.za>


Peter Waller <peter.waller at gmail.com> added the comment:

Apologies for the bump, but it has been more than a year and I did attach a patch! :-)

What next?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711800>
_______________________________________

From report at bugs.python.org  Wed Jun 15 17:07:45 2011
From: report at bugs.python.org (Peter Waller)
Date: Wed, 15 Jun 2011 15:07:45 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1308150465.57.0.304174764681.issue8668@psf.upfronthosting.co.za>


Changes by Peter Waller <peter.waller at gmail.com>:


----------
nosy: +Peter.Waller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Wed Jun 15 17:22:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Jun 2011 15:22:47 +0000
Subject: [issue12314] regrtest checks (os.environ, sys.path,
	etc.) are hard to use
In-Reply-To: <1307722749.85.0.48203387339.issue12314@psf.upfronthosting.co.za>
Message-ID: <1308151367.2.0.915799007641.issue12314@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Sounds like a plan.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12314>
_______________________________________

From report at bugs.python.org  Wed Jun 15 17:41:55 2011
From: report at bugs.python.org (OscarL)
Date: Wed, 15 Jun 2011 15:41:55 +0000
Subject: [issue12340] Access violation when using the C version of the io
	module
In-Reply-To: <1308152515.03.0.630952257185.issue12340@psf.upfronthosting.co.za>
Message-ID: <1308152515.03.0.630952257185.issue12340@psf.upfronthosting.co.za>


New submission from OscarL <oscar.lesta at gmail.com>:

This is on Windows XP SP2. Using Python 2.7.1 and 2.7.2.

While executing the unit tests of the PySerial package, version 2.5 (http://pypi.python.org/pypi/pyserial) one of the tests fails when using the C version of the io module ("io"), but pass if the pure Python version is used ("_pyio.py").

The specific test case in question is: test_iolib.py. When executed like:

    > python test_iolib.py loop://

the test fails with the following traceback:

----
Traceback (most recent call last):
  File "C:\pyserial-2.5\test\test_iolib.py", line 68, in test_hello_raw

    self.failUnlessEqual(hello, unicode("hello\n"))
AssertionError: u'<memory at 0x00C5D940>' != u'hello\n'
----

And Windows shows a crash report dialog, with the following information:

----
AppName: python.exe	 AppVer: 0.0.0.0	 ModName: python27.dll
ModVer: 2.7.2150.1013	 Offset: 00089f57

Exception Information
Code: 0xc0000005	Flags: 0x00000000
Record: 0x0000000000000000	Address: 0x000000001e089f57
----

As said above, if in the said test case, instead of "import io" one does "import _pyio as io", the crash does not happens, and the test succeeds.

----------
components: IO
messages: 138382
nosy: OscarL
priority: normal
severity: normal
status: open
title: Access violation when using the C version of the io module
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12340>
_______________________________________

From report at bugs.python.org  Wed Jun 15 17:45:19 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Jun 2011 15:45:19 +0000
Subject: [issue1711800] SequenceMatcher bug with insert/delete block after
	"replace"
Message-ID: <1308152719.35.0.805831590144.issue1711800@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No need to apologize for the bump.  The trick is catching the interest of someone who feels qualified to judge the patch.  I've added a couple people to nosy who worked on difflib recently.  If no one speaks up in the next few days, it might be time to post to python-dev.

----------
nosy: +eli.bendersky, r.david.murray, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711800>
_______________________________________

From report at bugs.python.org  Wed Jun 15 17:49:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Jun 2011 15:49:22 +0000
Subject: [issue12340] Access violation when using the C version of the io
	module
In-Reply-To: <1308152515.03.0.630952257185.issue12340@psf.upfronthosting.co.za>
Message-ID: <1308152962.29.0.553639285189.issue12340@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/issue12340>
_______________________________________

From report at bugs.python.org  Wed Jun 15 18:16:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Jun 2011 16:16:42 +0000
Subject: [issue11435] Links to source code should now point to hg repo
In-Reply-To: <1299519091.7.0.295996410449.issue11435@psf.upfronthosting.co.za>
Message-ID: <1308154602.81.0.429877621738.issue11435@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The 2.7 docs link to the Subversion repo.  Can I update them?

----------
nosy: +eric.araujo
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11435>
_______________________________________

From report at bugs.python.org  Wed Jun 15 18:22:02 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Jun 2011 16:22:02 +0000
Subject: [issue11102] configure doesn't find "major()" on HP-UX v11.31
In-Reply-To: <1296677130.56.0.432506284039.issue11102@psf.upfronthosting.co.za>
Message-ID: <1308154922.32.0.576921433602.issue11102@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, one way might be to set up and maintain an HP/UX buildbot :)

Other than that, just keep bugging us periodically until someone gets around to doing it.

----------
nosy: +r.david.murray
stage:  -> commit review
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11102>
_______________________________________

From report at bugs.python.org  Wed Jun 15 18:42:17 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 15 Jun 2011 16:42:17 +0000
Subject: [issue12341] Some additions to .hgignore
In-Reply-To: <1308156137.45.0.893152397766.issue12341@psf.upfronthosting.co.za>
Message-ID: <1308156137.45.0.893152397766.issue12341@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

following http://docs.python.org/devguide/coverage.html doc you'll end
up with several "new" files/dirs in your checkout:

- .coverage, used by coveragepy to save its info
- coverage/ , the symlink to coveragepy/coverage
- htmlcov/ , the dir where the coverage HTML pages are written

I think they should be added to .hgignore so that hg st won't show them, and the attached patch just does it. It's meant for 'default' but should there be no problem to backport it to previous branches.

----------
assignee: sandro.tosi
components: None
files: hgignore_additions-default.patch
keywords: patch
messages: 138386
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Some additions to .hgignore
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file22371/hgignore_additions-default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12341>
_______________________________________

From report at bugs.python.org  Wed Jun 15 18:44:48 2011
From: report at bugs.python.org (Michael Foord)
Date: Wed, 15 Jun 2011 16:44:48 +0000
Subject: [issue12341] Some additions to .hgignore
In-Reply-To: <1308156137.45.0.893152397766.issue12341@psf.upfronthosting.co.za>
Message-ID: <1308156288.79.0.690158549768.issue12341@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/issue12341>
_______________________________________

From report at bugs.python.org  Wed Jun 15 20:34:15 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 15 Jun 2011 18:34:15 +0000
Subject: [issue1711800] SequenceMatcher bug with insert/delete block after
	"replace"
Message-ID: <1308162855.87.0.913392854159.issue1711800@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I believe this issue should be closed and have set it to pending.

The original report of a 'bug' and the two 'testcases' were and are invalid as they are based on an incorrect understanding of SequenceMatcher. It is not a diff program and in particular not a line diff program but the function used internally by such. It works on sequences of characters, lines, numbers, or anything else. Given the character strings 'abc' and 'abcd\def' it correctly reports that the second is a copy of 3 chars from the first plus insertion of 5 more.

Gabriel correctly suggested the above in suggesting that if one wants to compare sequences of text lines, one might use Differ. One could also use SequenceMatcher directly, but this loses the diff-like formatting and report of within-line differences. I think this issue should have been closed then.

I do not know what functionality Andrew thinks Christian was talking about. Using Differ with

a = ['abc\n']
b = ['abcd\n', 'def\n']
for line in difflib.Differ().compare(a,b): print(line, end='')

# prints
- abc
+ abcd
?    +
+ def

One line is replaced with two, with the extra info that the first new line is the old line with an extra char. I do not believe that 'any diffing program' will report the latter. The '?' lines are easily filtered out if not wanted.

The patch by Peter has no motivation that I can see other than the idea that replacing a subsequence with one of a different length is somehow bad. Tim Peters did not think so and neither do I -- or Guido. Unequal replacement is built into the syntax of Python:

>>> s = [1,2,3]
>>> s[1:2] = [4,5,6]
>>> s
[1, 4, 5, 6, 3]

I would not be surprised it the proposed change broke some existing application or degraded performance a bit.

----------
assignee: tim_one -> 
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711800>
_______________________________________

From report at bugs.python.org  Wed Jun 15 20:35:18 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 15 Jun 2011 18:35:18 +0000
Subject: [issue1711800] SequenceMatcher bug with insert/delete block after
	"replace"
Message-ID: <1308162918.94.0.0547873626765.issue1711800@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711800>
_______________________________________

From report at bugs.python.org  Wed Jun 15 20:51:38 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 15 Jun 2011 18:51:38 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1308163898.62.0.885630114578.issue12191@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Here's the updated patch following review on Rietveld

----------
Added file: http://bugs.python.org/file22372/shutil_chown-default-v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Wed Jun 15 23:00:00 2011
From: report at bugs.python.org (wujek)
Date: Wed, 15 Jun 2011 21:00:00 +0000
Subject: [issue12342] characters with ord above 65535 fail conversion with
	str.format for '{:c}' in IDLE
In-Reply-To: <1308171600.34.0.388895530939.issue12342@psf.upfronthosting.co.za>
Message-ID: <1308171600.34.0.388895530939.issue12342@psf.upfronthosting.co.za>


New submission from wujek <wujek.srujek at googlemail.com>:

The following code produces an exception:

print('{:c}'.format(65536))

when executed in Idle 3.2. The stack trace:

>>> print('{:c}'.format(65536))
Traceback (most recent call last):
  File "<pyshell#149>", line 1, in <module>
    print('{:c}'.format(65536))
  File "/usr/lib/python3.2/idlelib/PyShell.py", line 1231, in write
    self.shell.write(s, self.tags)
  File "/usr/lib/python3.2/idlelib/PyShell.py", line 1213, in write
    OutputWindow.write(self, s, tags, "iomark")
  File "/usr/lib/python3.2/idlelib/OutputWindow.py", line 40, in write
    self.text.insert(mark, s, tags)
  File "/usr/lib/python3.2/idlelib/Percolator.py", line 25, in insert
    self.top.insert(index, chars, tags)
  File "/usr/lib/python3.2/idlelib/ColorDelegator.py", line 79, in insert
    self.delegate.insert(index, chars, tags)
  File "/usr/lib/python3.2/idlelib/PyShell.py", line 316, in insert
    UndoDelegator.insert(self, index, chars, tags)
  File "/usr/lib/python3.2/idlelib/UndoDelegator.py", line 81, in insert
    self.addcmd(InsertCommand(index, chars, tags))
  File "/usr/lib/python3.2/idlelib/UndoDelegator.py", line 116, in addcmd
    cmd.do(self.delegate)
  File "/usr/lib/python3.2/idlelib/UndoDelegator.py", line 219, in do
    text.insert(self.index1, self.chars, self.tags)
  File "/usr/lib/python3.2/idlelib/ColorDelegator.py", line 79, in insert
    self.delegate.insert(index, chars, tags)
  File "/usr/lib/python3.2/idlelib/WidgetRedirector.py", line 104, in __call__
    return self.tk_call(self.orig_and_operation + args)
ValueError: unsupported character

Seems to work fine in a terminal (Gnome-terminal in this case):

>>> print('{:c}'.format(0x10000))
?

(my font doesn't have the glyph, but otherwise it works)



Python version:
>>> print(sys.version)
3.2 (r32:88445, Mar 25 2011, 19:56:22) 
[GCC 4.5.2]

Os:
wujek at home:~$ uname -a
Linux studio 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

wujek at home:~$ cat /etc/issue
Ubuntu 11.04

----------
components: IDLE, IO
messages: 138389
nosy: wujek.srujek
priority: normal
severity: normal
status: open
title: characters with ord above 65535 fail conversion with str.format for '{:c}' in IDLE
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12342>
_______________________________________

From report at bugs.python.org  Wed Jun 15 23:10:08 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Jun 2011 21:10:08 +0000
Subject: [issue12342] characters with ord above 65535 fail to display in IDLE
In-Reply-To: <1308171600.34.0.388895530939.issue12342@psf.upfronthosting.co.za>
Message-ID: <1308172208.2.0.0290535667464.issue12342@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Judging from the stack trace, it isn't str.format that's failing, it's tk failing to display it.

----------
nosy: +r.david.murray, terry.reedy
title: characters with ord above 65535 fail conversion with str.format for '{:c}' in IDLE -> characters with ord above 65535 fail to display in IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12342>
_______________________________________

From report at bugs.python.org  Wed Jun 15 23:26:47 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 15 Jun 2011 21:26:47 +0000
Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in
	select()"
In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za>
Message-ID: <1308173207.15.0.93468966624.issue10527@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

[for reference: issue 11743 covered Antoine's rewrite of the connection class to be pure python, for 3.3 (re msg138310)]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10527>
_______________________________________

From report at bugs.python.org  Wed Jun 15 23:47:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jun 2011 21:47:18 +0000
Subject: [issue12342] characters with ord above 65535 fail to display in IDLE
In-Reply-To: <1308171600.34.0.388895530939.issue12342@psf.upfronthosting.co.za>
Message-ID: <1308174438.34.0.126715768211.issue12342@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

U+10000 is not the most common character in fonts. You should try another character in U+10000-U+10FFFF range (non-BMP characters). The new funny emoticon are in this range, but I don't know if your Ubuntu setup includes a font supporting this range.
http://www.unicode.org/charts/PDF/Unicode-6.0/U60-1F600.pdf

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12342>
_______________________________________

From report at bugs.python.org  Wed Jun 15 23:53:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jun 2011 21:53:42 +0000
Subject: [issue12133] ResourceWarning in urllib.request
In-Reply-To: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>
Message-ID: <1308174822.4.0.352702661686.issue12133@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, I wrote a similar patch to kill the ResourceWarning of test_pypi_simple (except that I didn't patch test_urllib2).

----------
nosy: +haypo
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12133>
_______________________________________

From report at bugs.python.org  Wed Jun 15 23:57:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jun 2011 21:57:24 +0000
Subject: [issue10883] urllib: socket is not closed explicitly
In-Reply-To: <1294698764.05.0.403920474459.issue10883@psf.upfronthosting.co.za>
Message-ID: <1308175044.7.0.717084935448.issue10883@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Is there still something to do in this issue? The initial report is fixed.

----------
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10883>
_______________________________________

From report at bugs.python.org  Wed Jun 15 23:59:07 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Jun 2011 21:59:07 +0000
Subject: [issue12342] characters with ord above 65535 fail to display in IDLE
In-Reply-To: <1308171600.34.0.388895530939.issue12342@psf.upfronthosting.co.za>
Message-ID: <1308175147.2.0.911325639711.issue12342@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

>From the discussions here, http://wiki.tcl.tk/1364, it appears that Tcl 8.5 (and earlier) does not support Unicode code points outside the BMP range as in this example. I don't think there is anything practical IDLE or tkinter can do about that.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12342>
_______________________________________

From report at bugs.python.org  Thu Jun 16 00:01:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Jun 2011 22:01:10 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <E1QWy94-0002jp-Fn@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset fd6446a88fe3 by Victor Stinner in branch 'default':
Issue #12167: Fix a reafleak in packaging.tests.PyPIServer constructor
http://hg.python.org/cpython/rev/fd6446a88fe3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Thu Jun 16 00:01:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jun 2011 22:01:49 +0000
Subject: [issue12342] characters with ord above 65535 fail to display in IDLE
In-Reply-To: <1308171600.34.0.388895530939.issue12342@psf.upfronthosting.co.za>
Message-ID: <1308175309.9.0.541984339275.issue12342@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> From the discussions here, http://wiki.tcl.tk/1364, it appears that Tcl
> 8.5 (and earlier) does not support Unicode code points outside
> the BMP range as in this example.

Extract of http://wiki.tcl.tk/1364 :

"RS 2008-07-09: Unicode out of BMP (> U+FFFF) requires a deeper rework of Tcl and Tk: we'd need 32 bit chars and/or surrogate pairs. UTF-8 at least can deal with 31-bit Unicodes by principle."

> I don't think there is anything practical IDLE
> or tkinter can do about that.

We might raise an error with better error message than ValueError('unsupported character'), but it's maybe overkill.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12342>
_______________________________________

From report at bugs.python.org  Thu Jun 16 00:04:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jun 2011 22:04:05 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1308175445.43.0.149786162894.issue12167@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_dist and test_bdist_dumb leak because of the _path_created global variable of packaging.util, used indirectly by copy_tree().

# cache for by mkpath() -- in addition to cheapening redundant calls,
# eliminates redundant "creating /foo/bar/baz" messages in dry-run mode
_path_created = set()

I don't how/when this set should be cleared.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Thu Jun 16 00:05:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jun 2011 22:05:14 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1308175514.39.0.158852085121.issue12167@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Note: #12133 has a patch to fix the ResourceWarning of test_pypi_simple.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Thu Jun 16 00:10:20 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 15 Jun 2011 22:10:20 +0000
Subject: [issue10883] urllib: socket is not closed explicitly
In-Reply-To: <1294698764.05.0.403920474459.issue10883@psf.upfronthosting.co.za>
Message-ID: <1308175820.76.0.581154953687.issue10883@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Yes, the fix I provided only eliminated some of the warnings. As of fd6446a88fe3, test_urllib2net still leaks 5 sockets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10883>
_______________________________________

From report at bugs.python.org  Thu Jun 16 00:10:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jun 2011 22:10:24 +0000
Subject: [issue12263] punycode codec ignores the error handler argument
In-Reply-To: <1307229378.45.0.142684435058.issue12263@psf.upfronthosting.co.za>
Message-ID: <1308175824.42.0.224582498974.issue12263@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

punycode_errors.patch:
 - raise an error if errors="replace": only accept strict and ignore
 - use errors to encode/decode to/from ASCII
 - add unit tests

I don't think that the change should be documented, because punycode has no section in Doc/library/codecs.rst, and I hope that nobody uses something different than strict :-)

----------
keywords: +patch
nosy: +loewis
Added file: http://bugs.python.org/file22373/punycode_errors.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12263>
_______________________________________

From report at bugs.python.org  Thu Jun 16 00:17:21 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Jun 2011 22:17:21 +0000
Subject: [issue12342] characters with ord above 65535 fail to display in IDLE
In-Reply-To: <1308171600.34.0.388895530939.issue12342@psf.upfronthosting.co.za>
Message-ID: <1308176241.22.0.658042745839.issue12342@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It looks like that error message has been in _tkinter.c since 2002: http://svn.python.org/view/python/trunk/Modules/_tkinter.c?r1=28989&r2=28990&

I suppose it could be slightly more informative but it seems pretty unambiguous to me.  Martin, any opinions?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12342>
_______________________________________

From report at bugs.python.org  Thu Jun 16 00:29:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Jun 2011 22:29:02 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>
Message-ID: <1308176942.86.0.122290496561.issue12328@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> pipe_interruptible.patch is a patch to support to making poll()
> interruptible.  It applies on top of pipe_poll_2.patch.

Hmm, it seems to me that it should be done in _poll() instead. Otherwise, recv() will not be interruptible, will it?

Also, after looking at this again, it seems sigint_event would be better provided (at the C level) by the Python core, e.g. as _PyOS_SigintEvent. The time module already uses a similar mechanism.

By setting the event in the sigint handler itself, rather than in an auxiliary HandlerRoutine callback function, it should also ensure that, when the event is set, the "tripped" bit in signalmodule.c has been set, meaning we wouldn't need to Sleep() anymore.

(I also wonder why the event isn't auto-reset. Otherwise, there's a race condition - which is probably harmless in most cases, but still.)

----------
nosy: +brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Thu Jun 16 00:46:58 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 15 Jun 2011 22:46:58 +0000
Subject: [issue12340] Access violation when using the C version of the io
	module
In-Reply-To: <1308152515.03.0.630952257185.issue12340@psf.upfronthosting.co.za>
Message-ID: <1308178018.25.0.203433221469.issue12340@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Regarding the crash,

>From what I can see, the `tp_clear` method of bufferedrwpair is called during Py_Finalize() that leads to garbage collection. This NULLs `self->writer` for the rwpair object.

Later, in the same garbage collection routine, the `tp_clear` of textio (the wrapper) is called. This attempts to finalize its wrapped object by first calling the `closed` property of the wrapped object. This property read is propagated down to the wrapped bufferedrwpair, `bufferedrwpair_closed_get()`.

At this point, `self->writer` for the bufferedrwpair object is already NULL from the previous clear. Hence, the crash happens because a NULL pointer dereferencing is attempted.

----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12340>
_______________________________________

From report at bugs.python.org  Thu Jun 16 02:07:06 2011
From: report at bugs.python.org (Mads Kiilerich)
Date: Thu, 16 Jun 2011 00:07:06 +0000
Subject: [issue12000] SSL certificate verification failed if no dNSName entry
	in subjectAltName
In-Reply-To: <1304754517.36.0.568196346631.issue12000@psf.upfronthosting.co.za>
Message-ID: <4DF94924.7010700@kiilerich.com>


Mads Kiilerich <mads at kiilerich.com> added the comment:

Nicolas Bareil wrote, On 05/07/2011 09:48 AM:
> Do you think this test should fail?

Until now I have considered this behaviour OK but undocumented and 
officially unsupported in Python. One (the best?) reason for considering 
it OK is that if someone (intentionally or not) trusts a certificate 
that happens to have the textual representation of an IP address in 
commonName then there is no doubt what the intention with that is. This 
case is thus within what i considered secure behaviour.

But the more I look at it the more convinced I get that this test should 
fail. RFC 2818 mentions subjectAltName iPAddress as a "must" for IP 
addresses - even though it only uses a lower-case and thus 
perhaps-not-necessarily-authoritative "must". But the best argument 
against IP in commonName is that it isn't mentioned anywhere, and when 
it isn't explicitly permitted we should consider it forbidden.

A consequence of that is that my previous concern is invalid. There is 
no reason the presence of a subjectAltName iPAddress should prevent 
fallback from dNSName to commonName.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12000>
_______________________________________

From report at bugs.python.org  Thu Jun 16 02:27:44 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 16 Jun 2011 00:27:44 +0000
Subject: [issue12340] Access violation when using the C version of the io
	module
In-Reply-To: <1308152515.03.0.630952257185.issue12340@psf.upfronthosting.co.za>
Message-ID: <1308184064.38.0.71822852571.issue12340@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Can you produce a self-contained test case?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12340>
_______________________________________

From report at bugs.python.org  Thu Jun 16 02:32:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jun 2011 00:32:23 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1308184343.05.0.122800675754.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 4 (mbcs4.patch):
 - fix encode and decode flags depending on the code page and Windows version, e.g. use WC_ERR_INVALID_CHARS instead of WC_NO_BEST_FIT_CHARS for CP_UTF8 on Windows Vista and later
 - fix usage of the default character on encoding, depending on the code page (incompatible with CP_UTF7 and CP_UTF8)
 - add some more unit tests
 - read the windows version only once, at startup
 - decode_code_page_chunk() now adjusts the input size depending on the final flag (it was done by decode_code_page_strict)

----------
Added file: http://bugs.python.org/file22374/mbcs4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Thu Jun 16 02:32:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jun 2011 00:32:30 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1308184350.31.0.420451365383.issue12281@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file22282/mbcs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Thu Jun 16 02:32:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jun 2011 00:32:33 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1308184353.94.0.940189001965.issue12281@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file22315/mbcs2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Thu Jun 16 02:32:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jun 2011 00:32:37 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1308184357.4.0.0737529037233.issue12281@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file22340/mbcs3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Thu Jun 16 03:26:08 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 16 Jun 2011 01:26:08 +0000
Subject: [issue12343] Python 2.7.2 regression: ssl.SSLError: [Errno 2]
	_ssl.c:503: The operation did not complete (read)
In-Reply-To: <1308187568.46.0.159826705626.issue12343@psf.upfronthosting.co.za>
Message-ID: <1308187568.46.0.159826705626.issue12343@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Combining non-blocking SSL sockets and "select()" raises "ssl.SSLError: [Errno 2] _ssl.c:503: The operation did not complete (read)" in Python 2.7.2, but works OK in 2.7.1, 2.6.* and previous.

This test shows the issue:

"""
import ssl
import socket
import select

s = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(("gmail.com", 443))
s.setblocking(0)
s = ssl.wrap_socket(s)
s.write("GET / HTTP/1.0\r\nHost: gmail.com\r\n\r\n")
select.select([s], [], [])

s.read(9999999)
print "OK!"
"""

Under python 2.6 and 2.7.1 I get "OK", but under 2.7.2 I get:

"""
Traceback (most recent call last):
  File "z.py", line 8, in <module>
    s = ssl.wrap_socket(s)
  File "/usr/local/lib/python2.7/ssl.py", line 372, in wrap_socket
    ciphers=ciphers)
  File "/usr/local/lib/python2.7/ssl.py", line 134, in __init__
    self.do_handshake()
  File "/usr/local/lib/python2.7/ssl.py", line 296, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [Errno 2] _ssl.c:503: The operation did not complete (read)
"""

Changing the order between the "s.setblocking()" and the "ssl.wrap_socket()" seems to solve the issue in this particular code sample, but this seems to be a serious regression in 2.7.2. I have programs in production here where changing the order doesn't solve the exception :-(. Dead in the water! :-(

----------
components: Extension Modules
messages: 138408
nosy: jcea
priority: critical
severity: normal
stage: needs patch
status: open
title: Python 2.7.2 regression: ssl.SSLError: [Errno 2] _ssl.c:503: The operation did not complete (read)
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12343>
_______________________________________

From report at bugs.python.org  Thu Jun 16 04:08:25 2011
From: report at bugs.python.org (higery)
Date: Thu, 16 Jun 2011 02:08:25 +0000
Subject: [issue12344] A kind of 'reinitialize_command' function which can
	initialize a command with key-value pair should be added for
	Command class
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>


New submission from higery <shoulderhigher at gmail.com>:

There is a 'reinitialize_command' function in setuptools' command class which can initialize a command with a key-value pair, but it seems that distutils2/packaging does not yet have this function. I think it's useful in the condition that we want to run some commands with some options initialized. 

For instance,  if we want to run 'build_ext' command with its 'inplace' option initialized, we can use : self.reinitialize_command('build_ext', inplace=1), and then self.run_command('build_ext') .

----------
assignee: tarek
components: Distutils2
messages: 138409
nosy: alexis, eric.araujo, higery, tarek
priority: normal
severity: normal
status: open
title: A kind of 'reinitialize_command' function which can initialize a command with key-value pair should be added for Command class
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Thu Jun 16 04:20:54 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 16 Jun 2011 02:20:54 +0000
Subject: [issue12342] characters with ord above 65535 fail to display in IDLE
In-Reply-To: <1308171600.34.0.388895530939.issue12342@psf.upfronthosting.co.za>
Message-ID: <1308190854.81.0.789878482151.issue12342@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12342>
_______________________________________

From report at bugs.python.org  Thu Jun 16 04:57:48 2011
From: report at bugs.python.org (Eugene Toder)
Date: Thu, 16 Jun 2011 02:57:48 +0000
Subject: [issue12290] __setstate__ is called for false values
In-Reply-To: <1307586060.34.0.652262251036.issue12290@psf.upfronthosting.co.za>
Message-ID: <1308193068.78.0.300705562738.issue12290@psf.upfronthosting.co.za>


Eugene Toder <eltoder at gmail.com> added the comment:

So how about this correction?

----------
keywords: +patch
nosy: +belopolsky, georg.brandl
Added file: http://bugs.python.org/file22375/setstate.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12290>
_______________________________________

From report at bugs.python.org  Thu Jun 16 04:59:50 2011
From: report at bugs.python.org (Eugene Toder)
Date: Thu, 16 Jun 2011 02:59:50 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1308193190.69.0.0732178866496.issue5996@psf.upfronthosting.co.za>


Eugene Toder <eltoder at gmail.com> added the comment:

Anyone has any thoughts on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Thu Jun 16 05:10:30 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 16 Jun 2011 03:10:30 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

I'd like to add a new constant to the math module:

  tau = 2*math.pi

Rather than repeating all the reasons for why tau makes more sense than pi as the fundamental circle constant, I'll just refer interested readers to http://tauday.com/

----------
keywords: easy
messages: 138412
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add math.tau
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Thu Jun 16 05:26:04 2011
From: report at bugs.python.org (Eugene Toder)
Date: Thu, 16 Jun 2011 03:26:04 +0000
Subject: [issue11549] Build-out an AST optimizer,
	moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1308194764.13.0.874160684299.issue11549@psf.upfronthosting.co.za>


Eugene Toder <eltoder at gmail.com> added the comment:

I found a problem in constant de-duplication, already performed by compiler, that needs to be fixed before this change can be merged. 

Compiler tries to eliminate duplicate constants by putting them into a dict. However, "duplicate" in this case doesn't mean just "equal", we need a stronger relationship, as there are many equal values that behave differently in some contexts, e.g. 0 and 0.0 and False or 0.0 and -0.0. To this end for each value we create a tuple of the value and it's type and have some logic for -0.0. This is handled in compiler_add_o in Python/compile.c.

This logic, however, only works for scalar values -- if we get a container with 0 and the same container with False we collapse them into one. This was not a problem before, because constant tuples were only created by peephole, which doesn't attempt de-duplication. If tuple folding is moved to AST we start hitting this problem:

>>> dis(lambda: print((0,1),(False,True)))
  1           0 LOAD_GLOBAL              0 (print)
              3 LOAD_CONST               1 ((0, 1))
              6 LOAD_CONST               1 ((0, 1))
              9 CALL_FUNCTION            2
             12 RETURN_VALUE

The cleanest solution seems to be to introduce a new rich comparison code: Py_EQUIV (equivalent) and implement it at least in types that we support in marshal. This will simplify compiler_add_o quite a bit and make it work for tuples and frozensets.
I'm open to other suggestions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11549>
_______________________________________

From report at bugs.python.org  Thu Jun 16 05:50:35 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 16 Jun 2011 03:50:35 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1308196235.17.0.540312306525.issue12345@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Perhaps we should wait until \tau gains popularity larger than some impassioned physicist. \tau has been used to represent the golden ratio longer.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Thu Jun 16 08:06:03 2011
From: report at bugs.python.org (Derek Wilson)
Date: Thu, 16 Jun 2011 06:06:03 +0000
Subject: [issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
In-Reply-To: <1242668944.28.0.292370665479.issue6056@psf.upfronthosting.co.za>
Message-ID: <1308204363.74.0.497901037683.issue6056@psf.upfronthosting.co.za>


Derek Wilson <jderekwilson at gmail.com> added the comment:

While having multiprocessing use a timeout would be great, I didn't really have the time to fiddle with the c code.

Instead of using the socket timeout, I'm modifying all the sockets created by the socket module to have no timeout (and thus to be blocking) which makes the multiprocessing module 'immune' to the socket module's default timeout.

For testing, I just run the test suite twice, once with the initial default socket timeout and once with a 60 second timeout. Nothing there failed with this issue.

It is worth noting, however, that when using a default socket timeout, for some reason processes that have have put data into a queue no longer block at exit waiting for the data to be consumed. I'm not sure if there is some additional cleanup code that uses sockets and might need to block? Or maybe whatever the issue was with blocking sockets is not an issue with non-blocking sockets?

----------
keywords: +patch
Added file: http://bugs.python.org/file22376/mpsock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6056>
_______________________________________

From report at bugs.python.org  Thu Jun 16 08:12:23 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Jun 2011 06:12:23 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1308204743.65.0.356801357092.issue12345@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/issue12345>
_______________________________________

From report at bugs.python.org  Thu Jun 16 10:14:24 2011
From: report at bugs.python.org (Graeme Winter)
Date: Thu, 16 Jun 2011 08:14:24 +0000
Subject: [issue12346] Python 2.7.2 source code build (release) depends on
	mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>


New submission from Graeme Winter <xia2.support at gmail.com>:

Trying to build 2.7.2 from source on RHEL5 32 bit get errors:

gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE \
              -DSVNVERSION="\"`LC_ALL=C svnversion .`\"" \
              -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
hg identify: option -i not recognized
hg identify: option -t not recognized
hg identify: option -b not recognized
./Modules/getbuildinfo.c: In function ?Py_GetBuildInfo?:
./Modules/getbuildinfo.c:45: error: missing terminating " character
./Modules/getbuildinfo.c:45: error: expected expression before ?)? token
./Modules/getbuildinfo.c:46: error: missing terminating " character
./Modules/getbuildinfo.c:46: error: missing terminating " character
./Modules/getbuildinfo.c:47: error: missing terminating " character
./Modules/getbuildinfo.c:47: error: missing terminating " character
./Modules/getbuildinfo.c:53: error: ?buildinfo? undeclared (first use in this function)
./Modules/getbuildinfo.c:53: error: (Each undeclared identifier is reported only once
./Modules/getbuildinfo.c:53: error: for each function it appears in.)
./Modules/getbuildinfo.c: In function ?_Py_hgversion?:
./Modules/getbuildinfo.c:72: error: missing terminating " character
./Modules/getbuildinfo.c:72: warning: ?return? with no value, in function returning non-void
./Modules/getbuildinfo.c: In function ?_Py_hgidentifier?:
./Modules/getbuildinfo.c:79: error: missing terminating " character
./Modules/getbuildinfo.c:79: error: expected expression before ?;? token
./Modules/getbuildinfo.c:83: error: missing terminating " character
./Modules/getbuildinfo.c:83: error: expected expression before ?;? token
make: *** [Modules/getbuildinfo.o] Error 1
gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE \
              -DSVNVERSION="\"`LC_ALL=C svnversion .`\"" \
              -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
hg identify: option -i not recognized
hg identify: option -t not recognized
hg identify: option -b not recognized
./Modules/getbuildinfo.c: In function ?Py_GetBuildInfo?:
./Modules/getbuildinfo.c:45: error: missing terminating " character
./Modules/getbuildinfo.c:45: error: expected expression before ?)? token
./Modules/getbuildinfo.c:46: error: missing terminating " character
./Modules/getbuildinfo.c:46: error: missing terminating " character
./Modules/getbuildinfo.c:47: error: missing terminating " character
./Modules/getbuildinfo.c:47: error: missing terminating " character
./Modules/getbuildinfo.c:53: error: ?buildinfo? undeclared (first use in this function)
./Modules/getbuildinfo.c:53: error: (Each undeclared identifier is reported only once
./Modules/getbuildinfo.c:53: error: for each function it appears in.)
./Modules/getbuildinfo.c: In function ?_Py_hgversion?:
./Modules/getbuildinfo.c:72: error: missing terminating " character
./Modules/getbuildinfo.c:72: warning: ?return? with no value, in function returning non-void
./Modules/getbuildinfo.c: In function ?_Py_hgidentifier?:
./Modules/getbuildinfo.c:79: error: missing terminating " character
./Modules/getbuildinfo.c:79: error: expected expression before ?;? token
./Modules/getbuildinfo.c:83: error: missing terminating " character
./Modules/getbuildinfo.c:83: error: expected expression before ?;? token
make: *** [Modules/getbuildinfo.o] Error 1

Would assume it is bad form for a release source bundle to depend on mercurial?

Diffs against version of getbuildinfo.c from 2.7.1 indicate that this is a new dependency:

$ find . -name 'getbuildinfo.c'  | xargs diff -u
--- ./Python-2.7.2/Modules/getbuildinfo.c       2011-06-11 16:46:27.000000000 +0100
+++ ./Python-2.7.1/Modules/getbuildinfo.c       2010-05-09 15:46:46.000000000 +0100
@@ -28,30 +28,15 @@
 #define SVNVERSION "$WCRANGE$$WCMODS?M:$"
 #endif

-/* XXX Only unix build process has been tested */
-#ifndef HGVERSION
-#define HGVERSION ""
-#endif
-#ifndef HGTAG
-#define HGTAG ""
-#endif
-#ifndef HGBRANCH
-#define HGBRANCH ""
-#endif
-
 const char *
 Py_GetBuildInfo(void)
 {
-    static char buildinfo[50 + sizeof(HGVERSION) +
-                          ((sizeof(HGTAG) > sizeof(HGBRANCH)) ?
-                           sizeof(HGTAG) : sizeof(HGBRANCH))];
-    const char *revision = _Py_hgversion();
+    static char buildinfo[50];
+    const char *revision = Py_SubversionRevision();
     const char *sep = *revision ? ":" : "";
-    const char *hgid = _Py_hgidentifier();
-    if (!(*hgid))
-        hgid = "default";
+    const char *branch = Py_SubversionShortBranch();
     PyOS_snprintf(buildinfo, sizeof(buildinfo),
-                  "%s%s%s, %.20s, %.9s", hgid, sep, revision,
+                  "%s%s%s, %.20s, %.9s", branch, sep, revision,
                   DATE, TIME);
     return buildinfo;
 }
@@ -65,21 +50,3 @@
         return svnversion; /* it was interpolated, or passed on command line */
     return "Unversioned directory";
 }
-
-const char *
-_Py_hgversion(void)
-{
-    return HGVERSION;
-}
-
-const char *
-_Py_hgidentifier(void)
-{
-    const char *hgtag, *hgid;
-    hgtag = HGTAG;
-    if ((*hgtag) && strcmp(hgtag, "tip") != 0)
-        hgid = hgtag;
-    else
-        hgid = HGBRANCH;
-    return hgid;
-}

----------
components: Build
messages: 138417
nosy: Graeme.Winter
priority: normal
severity: normal
status: open
title: Python 2.7.2 source code build (release) depends on mercurial
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12346>
_______________________________________

From report at bugs.python.org  Thu Jun 16 10:24:43 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 16 Jun 2011 08:24:43 +0000
Subject: [issue12313] make install misses packaging module
In-Reply-To: <1307722082.95.0.13819638115.issue12313@psf.upfronthosting.co.za>
Message-ID: <1308212683.2.0.551707265185.issue12313@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It's not packaging-related, but other directories are also missing from LIBSUBDIRS:

test/test_email test/test_email/data

IMO it's not ideal to use find(1), as in theory a developer may have some directories with matching names in the source build that they don't want installed - or would that be a no-no?

Ideally at least one buildbot should be set up to install and then test the new installation - I presume this error wasn't caught on the buildbots as they all test source builds?

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12313>
_______________________________________

From report at bugs.python.org  Thu Jun 16 10:24:49 2011
From: report at bugs.python.org (higery)
Date: Thu, 16 Jun 2011 08:24:49 +0000
Subject: [issue12344] A kind of 'reinitialize_command' function which can
	initialize a command with key-value pair should be added for
	Command class
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1308212689.87.0.0411979680549.issue12344@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


----------
hgrepos: +28

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Thu Jun 16 10:32:01 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 16 Jun 2011 08:32:01 +0000
Subject: [issue12313] make install misses test dirs for packaging and email
	modules
In-Reply-To: <1307722082.95.0.13819638115.issue12313@psf.upfronthosting.co.za>
Message-ID: <1308213121.87.0.0138568479459.issue12313@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
nosy: +r.david.murray
title: make install misses packaging module -> make install misses test dirs for packaging and email modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12313>
_______________________________________

From report at bugs.python.org  Thu Jun 16 12:32:20 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 16 Jun 2011 10:32:20 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1308220340.35.0.524488750936.issue12345@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The golden ratio is more commonly denoted with phi (although tau does get used sometimes).

Popularity isn't the point though, it's the fact that tau *makes geometric sense* in ways that 2*pi doesn't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Thu Jun 16 12:41:36 2011
From: report at bugs.python.org (Graeme Winter)
Date: Thu, 16 Jun 2011 10:41:36 +0000
Subject: [issue12346] Python 2.7.2 source code build (release) depends on
	mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1308220896.74.0.810254280593.issue12346@psf.upfronthosting.co.za>


Graeme Winter <xia2.support at gmail.com> added the comment:

Some more information:

It has picked up that I have mercurial installed:


[gw56 at ws050 Python-2.7.2_cci]$ cat config.log | grep HG
ac_cv_prog_HAS_HG=found
HAS_HG='found'
HGBRANCH='hg id -b $(srcdir)'
HGTAG='hg id -t $(srcdir)'
HGVERSION='hg id -i $(srcdir)'


however it happens to be rather an old version:


[gw56 at ws050 Python-2.7.2_cci]$ hg --version
Mercurial Distributed SCM (version 0.9.3)

Copyright (C) 2005, 2006 Matt Mackall <mpm at selenic.com>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


so does not recognise the command-line options that you are using.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12346>
_______________________________________

From report at bugs.python.org  Thu Jun 16 12:43:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jun 2011 10:43:28 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1308221008.15.0.956600035235.issue12345@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I like this issue number, but I don't think that Python needs this new constant: it's trivial to add it to your own project. We have pi and e, it's enough. If we begin to add a new constant, others will ask to add much more constants, and there are million of other constants (useful or not). You may want to create a library of some other common constants. You can use float.fromhex() to have a good accuracy.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Thu Jun 16 13:16:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Jun 2011 11:16:59 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1308223019.14.0.0254344587722.issue12345@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Nick, you just have to write: tau = 2 * math.pi
and you're done.

> there are million of other constants

Actually, I've heard there are an infinity of them.

----------
nosy: +pitrou
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Thu Jun 16 13:31:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jun 2011 11:31:46 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1308223906.53.0.0162480618722.issue12345@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Actually, I've heard there are an infinity of them.

Can you prove that?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Thu Jun 16 13:40:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Jun 2011 11:40:47 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1308224447.74.0.0580233721055.issue12345@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Thu Jun 16 13:48:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Jun 2011 11:48:27 +0000
Subject: [issue12343] Python 2.7.2 regression: ssl.SSLError: [Errno 2]
	_ssl.c:503: The operation did not complete (read)
In-Reply-To: <1308187568.46.0.159826705626.issue12343@psf.upfronthosting.co.za>
Message-ID: <1308224907.16.0.0714937373315.issue12343@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is not a bug. With a non-blocking socket, the handshake itself is non-blocking, so you have to be prepared to retry. Your snippet also fails under Python 2.6 for me, so this isn't a regression either.

If you want to know how to do a non-blocking handshake, see e.g. 
http://hg.python.org/cpython/file/fd6446a88fe3/Lib/test/test_ssl.py#l632
or (using asyncore)
http://hg.python.org/cpython/file/fd6446a88fe3/Lib/test/test_ftplib.py#l299

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12343>
_______________________________________

From report at bugs.python.org  Thu Jun 16 14:45:51 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 16 Jun 2011 12:45:51 +0000
Subject: [issue12343] Python 2.7.2 regression: ssl.SSLError: [Errno 2]
	_ssl.c:503: The operation did not complete (read)
In-Reply-To: <1308187568.46.0.159826705626.issue12343@psf.upfronthosting.co.za>
Message-ID: <1308228351.11.0.935490298159.issue12343@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I am not getting the error in the handshake. I am getting it when transfering data, after a few Kbytes are already transfered.

This code has been working for the last 8 years, including 2.7.1. It is failing now, under 2.7.2. OpenSSL version haven't changed since 2.7.1.

So, it is something working under 2.7.1 that is not working under 2.7.2.

If you get an error in 2.6, I guess this is somewhat dependent of the OpenSSL version or OS. I am running Ubuntu 10.04, OpenSSL 0.9.8k-7ubuntu8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12343>
_______________________________________

From report at bugs.python.org  Thu Jun 16 14:47:41 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 16 Jun 2011 12:47:41 +0000
Subject: [issue12343] Python 2.7.2 regression: ssl.SSLError: [Errno 2]
	_ssl.c:503: The operation did not complete (read)
In-Reply-To: <1308187568.46.0.159826705626.issue12343@psf.upfronthosting.co.za>
Message-ID: <1308228461.63.0.0433596441505.issue12343@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I am talking about the code in production, not the code I pasted yesterday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12343>
_______________________________________

From report at bugs.python.org  Thu Jun 16 14:53:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Jun 2011 12:53:19 +0000
Subject: [issue12343] Python 2.7.2 regression: ssl.SSLError: [Errno 2]
	_ssl.c:503: The operation did not complete (read)
In-Reply-To: <1308187568.46.0.159826705626.issue12343@psf.upfronthosting.co.za>
Message-ID: <1308228799.63.0.499619299795.issue12343@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I am not getting the error in the handshake. I am getting it when
> transfering data, after a few Kbytes are already transfered.

Your traceback (and mine as well) occurs in wrap_socket() which itself calls do_handshake(). I don't understand how you could have transferred data *before* the SSL session is established. Or perhaps the test you posted doesn't reflect the actual issue?

By the way, faulty non-blocking code can work out of pure luck, if the target server and Internet connection is faster than the local computer...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12343>
_______________________________________

From report at bugs.python.org  Thu Jun 16 14:55:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Jun 2011 12:55:39 +0000
Subject: [issue12343] Python 2.7.2 regression: ssl.SSLError: [Errno 2]
	_ssl.c:503: The operation did not complete (read)
In-Reply-To: <1308187568.46.0.159826705626.issue12343@psf.upfronthosting.co.za>
Message-ID: <1308228939.41.0.115912010933.issue12343@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ah, ok, looks like your messages crossed each other. Can you try to devise another test case, then?
Or, at least, explain the context and how and where it fails?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12343>
_______________________________________

From report at bugs.python.org  Thu Jun 16 15:17:14 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 16 Jun 2011 13:17:14 +0000
Subject: [issue12343] Python 2.7.2 regression: ssl.SSLError: [Errno 2]
	_ssl.c:503: The operation did not complete (read)
In-Reply-To: <1308187568.46.0.159826705626.issue12343@psf.upfronthosting.co.za>
Message-ID: <1308230234.45.0.572872066534.issue12343@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Protecting my "reads" retrying when getting this exception does the trick, but now my code is convoluted and never before I had to manage this directly. This worked fine in 2.7.1. Previously Python seemed to do the retry itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12343>
_______________________________________

From report at bugs.python.org  Thu Jun 16 15:20:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Jun 2011 13:20:15 +0000
Subject: [issue12343] Python 2.7.2 regression: ssl.SSLError: [Errno 2]
	_ssl.c:503: The operation did not complete (read)
In-Reply-To: <1308187568.46.0.159826705626.issue12343@psf.upfronthosting.co.za>
Message-ID: <1308230415.88.0.74901088892.issue12343@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Note: the only significant changes in the ssl module on branch 2.7 have been 742d73a99425 and 7f99ac53014a.

> Protecting my "reads" retrying when getting this exception does the
> trick, but now my code is convoluted and never before I had to manage
> this directly. This worked fine in 2.7.1. Previously Python seemed to
> do the retry itself.

I'm sure it didn't. I think you were just lucky that you had enough data to satisfy the read. With non-blocking code, by definition you have to be prepared to retry. That's especially true when using SSL, because having bytes available on the socket (as signalled by select()) doesn't mean there's anything to read on the SSL layer (for example, the bytes may not form a complete SSL frame).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12343>
_______________________________________

From report at bugs.python.org  Thu Jun 16 15:20:31 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 16 Jun 2011 13:20:31 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308223906.53.0.0162480618722.issue12345@psf.upfronthosting.co.za>
Message-ID: <BANLkTikO=KkRbcOX3KKct=twD0T7o=FAwQ@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/6/16 STINNER Victor <report at bugs.python.org>:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
>> Actually, I've heard there are an infinity of them.
>
> Can you prove that?

Don't have to. Axiom of infinity. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Thu Jun 16 15:44:23 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 16 Jun 2011 13:44:23 +0000
Subject: [issue12343] Python 2.7.2 regression: ssl.SSLError: [Errno 2]
	_ssl.c:503: The operation did not complete (read)
In-Reply-To: <1308187568.46.0.159826705626.issue12343@psf.upfronthosting.co.za>
Message-ID: <1308231863.32.0.628018467402.issue12343@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I have write a testcase, but adding a small delay between reads, allowing more data coming from the server, solves the issue, so this seems to be a race condition. Trying with a remote slow SSL server, I get the same error in python 2.6, so I guess I was being lucky for the last 8 years :-/.

Pitrou, just confirm me that I must catch & retry the exception in all my READ/WRITE, not only in the handshake.

Thanks, and sorry for wasting your time. I know about this SSL details, but my code worked just fine until 2.7.2...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12343>
_______________________________________

From report at bugs.python.org  Thu Jun 16 15:51:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jun 2011 13:51:30 +0000
Subject: [issue12343] Python 2.7.2 regression: ssl.SSLError: [Errno 2]
	_ssl.c:503: The operation did not complete (read)
In-Reply-To: <1308187568.46.0.159826705626.issue12343@psf.upfronthosting.co.za>
Message-ID: <1308232290.73.0.496724972863.issue12343@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It's maybe because Python 2.7.2 is faster/slower? :-)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12343>
_______________________________________

From report at bugs.python.org  Thu Jun 16 15:57:28 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 16 Jun 2011 13:57:28 +0000
Subject: [issue12343] Python 2.7.2 regression: ssl.SSLError: [Errno 2]
	_ssl.c:503: The operation did not complete (read)
In-Reply-To: <1308187568.46.0.159826705626.issue12343@psf.upfronthosting.co.za>
Message-ID: <1308232648.4.0.685425701824.issue12343@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Antoine, now I am worried about writes, since my usual aproach would be something like this:

"""
select says that it is Ok to try to write
buf = buf[socket.send(buf):]
"""

If now I can get a "retry" while writing, what is the logic?. Does Python retry automatically, internally?. Do I get a frame worth of ack and then the exception (in the next loop iteration), garanteeing nothing was written, or what?.

I think SSL module documentation should write down this captchas when using non-blocking sockets. That is, that read/write can raise exceptions even if "select" was OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12343>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:02:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Jun 2011 14:02:48 +0000
Subject: [issue12341] Some additions to .hgignore
In-Reply-To: <1308156137.45.0.893152397766.issue12341@psf.upfronthosting.co.za>
Message-ID: <1308232968.17.0.392878917115.issue12341@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also #12255.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12341>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:07:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Jun 2011 14:07:36 +0000
Subject: [issue12343] Python 2.7.2 regression: ssl.SSLError: [Errno 2]
	_ssl.c:503: The operation did not complete (read)
In-Reply-To: <1308187568.46.0.159826705626.issue12343@psf.upfronthosting.co.za>
Message-ID: <1308233256.64.0.032072932171.issue12343@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If now I can get a "retry" while writing, what is the logic?. Does
> Python retry automatically, internally?.

No, Python doesn't retry automatically. You have to call send() again with the same buffer.
(if Python retried, it would make non-blocking calls blocking)

Also, the args[0] of the SSL error tells you what the SSL layer is blocking on (SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE). 

Also, with the current setup, non-blocking write() will never succeed with a partial write. See issue12197.
(that doesn't mean nothing is written on the network, though. OpenSSL may start emitting bytes and keep track internally of what remains to be sent. The OpenSSL documentation isn't very clear on that, IIRC)

> I think SSL module documentation should write down this captchas when 
> using non-blocking sockets. That is, that read/write can raise
> exceptions even if "select" was OK.

Agreed.

Relatedly, there's issue10084 for SSL support in asyncore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12343>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:08:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Jun 2011 14:08:32 +0000
Subject: [issue12343] ssl documentation needs comments about non-blocking
	behaviour
In-Reply-To: <1308187568.46.0.159826705626.issue12343@psf.upfronthosting.co.za>
Message-ID: <1308233312.88.0.12334061854.issue12343@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

So let's turn this into a documentation issue, then.

----------
assignee:  -> docs at python
components: +Documentation, Library (Lib) -Extension Modules
nosy: +docs at python
priority: critical -> normal
resolution: invalid -> 
status: closed -> open
title: Python 2.7.2 regression: ssl.SSLError: [Errno 2] _ssl.c:503: The operation did not complete (read) -> ssl documentation needs comments about non-blocking behaviour
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12343>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:10:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Jun 2011 14:10:23 +0000
Subject: [issue12344] A kind of 'reinitialize_command' function which can
	initialize a command with key-value pair should be added for
	Command class
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1308233423.74.0.197537674274.issue12344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

As I told in another message, we have renamed the function to get_reinitialized_command, to make it consistent with other methods? names.  Instead of adding a function, can you update the existing one?

About the repository: You should not put the user in the URI.  Can you fix it?  The ?Create Patch? button doesn?t worK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:11:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Jun 2011 14:11:27 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1308233487.51.0.822406525353.issue8668@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
hgrepos: +29

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:12:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Jun 2011 14:12:13 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1308233533.25.0.518906582657.issue8668@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22377/aa68d35988bb.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:22:14 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 16 Jun 2011 14:22:14 +0000
Subject: [issue12347] add an "extras" in packaging.pypi.simple.Crawler
In-Reply-To: <1308234134.22.0.149772690275.issue12347@psf.upfronthosting.co.za>
Message-ID: <1308234134.22.0.149772690275.issue12347@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

It occurs to me that our Crawler don't allow us to specify extra locations, like easy_install or pypi

We should add that and let the crawler look up to these places because the index

----------
messages: 138439
nosy: alexis, tarek
priority: normal
severity: normal
status: open
title: add an "extras" in packaging.pypi.simple.Crawler
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12347>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:22:51 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 16 Jun 2011 14:22:51 +0000
Subject: [issue12197] non-blocking SSL write fails if a partial write was
	issued
In-Reply-To: <1306519609.32.0.152577977388.issue12197@psf.upfronthosting.co.za>
Message-ID: <1308234171.91.0.733885051984.issue12197@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/issue12197>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:22:57 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jun 2011 14:22:57 +0000
Subject: [issue12346] Python 2.7.2 source code build (release) depends on
	mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1308234177.47.0.709568039542.issue12346@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It used to be that the svn version info was pulled from embedded constants in Makefile.pre.in.  I agree that depending on having mercurial (and, presumably, a repo!) at build time is wrong.  These constants need to be pre-computed when a release tarball is built and the mercurial dependency removed from the generated Makefile.  I'm not sure how we make that work correctly in a development build, but I'm sure the release managers will figure something out.

----------
nosy: +benjamin.peterson, georg.brandl, r.david.murray
priority: normal -> release blocker
stage:  -> needs patch
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12346>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:24:04 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 16 Jun 2011 14:24:04 +0000
Subject: [issue12347] add an "extras" in packaging.pypi.simple.Crawler
In-Reply-To: <1308234134.22.0.149772690275.issue12347@psf.upfronthosting.co.za>
Message-ID: <1308234244.32.0.272984647404.issue12347@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12347>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:25:30 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 16 Jun 2011 14:25:30 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1308234330.45.0.606068067947.issue8240@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/issue8240>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:31:52 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 16 Jun 2011 14:31:52 +0000
Subject: [issue8222] enabling SSL_MODE_AUTO_RETRY on SSL sockets
In-Reply-To: <1269448401.87.0.655952787423.issue8222@psf.upfronthosting.co.za>
Message-ID: <1308234712.92.0.946067619861.issue8222@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/issue8222>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:34:22 2011
From: report at bugs.python.org (sbt)
Date: Thu, 16 Jun 2011 14:34:22 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>
Message-ID: <1308234862.44.0.262405628185.issue12328@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> Hmm, it seems to me that it should be done in _poll() instead. 
> Otherwise, recv() will not be interruptible, will it?

Or maybe WaitForMultipleObjects() should be changed to also wait on sigint_event if called by the main thread.

> Also, after looking at this again, it seems sigint_event would be 
> better provided (at the C level) by the Python core, e.g. as 
> _PyOS_SigintEvent. The time module already uses a similar mechanism.

> By setting the event in the sigint handler itself, rather than in an 
> auxiliary HandlerRoutine callback function, it should also ensure 
> that, when the event is set, the "tripped" bit in signalmodule.c 
> has been set, meaning we wouldn't need to Sleep() anymore.

> (I also wonder why the event isn't auto-reset. Otherwise, there's a 
> race condition - which is probably harmless in most cases, but still.)

If it is an auto-reset event then we must worry about a non-main thread stealing the event.  Maybe _PyOS_SigintEvent() should return NULL if called by a non-main thread, and be documented with a loud usage warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:34:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jun 2011 14:34:53 +0000
Subject: [issue12346] Python 2.7.2 source code build (release) depends on
	mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1308234893.98.0.765839889858.issue12346@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Indeed, I just confirmed that building with a recent version of mercurial installed from the release 2.7.2 source tarball from python.org, the make results in:

abort: repository . not found!
abort: repository . not found!
abort: repository . not found!

during the build of getbuildinfo.c.  Fortunately the only effect seems to be that sys._mercurial returns ('CPython, '', '') instead of the correct info.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12346>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:40:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jun 2011 14:40:07 +0000
Subject: [issue12313] make install misses test dirs for packaging and email
	modules
In-Reply-To: <1307722082.95.0.13819638115.issue12313@psf.upfronthosting.co.za>
Message-ID: <1308235207.34.0.691237319771.issue12313@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Fixing the missing dirs for email has been on my todo list for a while but obviously hasn't gotten done yet.  I talked with Antoine about setting up a buildbot that tested an installed version, but I'm not sure when I'll get around to trying *that* either.  And in any case, even that would not have caught the test_email omission, since rergrtest uses filename-based discovery to select the tests to run, so it would not have noticed that test_email was missing.  I suppose that is a disadvantage of having regrtest recognize test packages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12313>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:43:30 2011
From: report at bugs.python.org (Peter Waller)
Date: Thu, 16 Jun 2011 14:43:30 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1308235410.54.0.443416799893.issue8668@psf.upfronthosting.co.za>


Peter Waller <peter.waller at gmail.com> added the comment:

Hi - Great to see this functionality coming. There is one feature of it that I would really like to see fixed, which is currently broken in setuptools/distribute - I'm sorry if this is the wrong forum for this note, but I wanted to add it to the discussion somewhere.

That feature is the "package_dir" argument to setup(). If the sources aren't in the root directory, the package doesn't function correctly with `python setup.py develop`

Here is a reference to an issue filed against distribute:

https://bitbucket.org/tarek/distribute/issue/177/setuppy-develop-doesnt-support-package_dir-arg-to

Is there any possibility of seeing this work correctly? A lot of packages use it, and for them, `develop` is currently broken.

Apologies if this feature is implemented and I missed it, but I see no reference to "package_dir" in the patch, so I would be (pleasantly) surprised if it was implemented. I would be happy to provide a testcase on request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Jun 16 16:51:29 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jun 2011 14:51:29 +0000
Subject: [issue12346] Python 2.7.2 source code build (release) depends on
	mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1308235889.37.0.894490325747.issue12346@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah.  For subversion there was a similar check, and the values were set to blank if the subversion binary was not found.  For hg it looks like we need to add additional checks on whether or not there is a repo.  (We can probably assume that if there is a repo the correct version of mercurial is installed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12346>
_______________________________________

From report at bugs.python.org  Thu Jun 16 17:07:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Jun 2011 15:07:20 +0000
Subject: [issue9302] distutils API Reference: setup() and Extension
	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1308236840.51.0.0480563365071.issue9302@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FYI, in one packaging doc I added one note instead of changing each cell: http://docs.python.org/dev/library/packaging.compiler#id6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9302>
_______________________________________

From report at bugs.python.org  Thu Jun 16 17:08:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Jun 2011 15:08:33 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1308236913.28.0.0912475423789.issue8668@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yes, this should of course be supported.

Note that in packaging, packages_dir has been simplified to packages_root, which means that all modules and packages must be in the same directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Jun 16 17:13:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Jun 2011 15:13:58 +0000
Subject: [issue5572] distutils ignores the LIBS configure env var
In-Reply-To: <1238095013.07.0.627782689433.issue5572@psf.upfronthosting.co.za>
Message-ID: <1308237238.78.0.778642682775.issue5572@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Reclassifying as a feature request for the packaging module.  The distutils docs don?t say using LIBS is supported and there aren?t many people asking for it on this bug report.

----------
components: +Distutils2 -Distutils
nosy: +alexis, eric.araujo
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5572>
_______________________________________

From report at bugs.python.org  Thu Jun 16 17:21:07 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 16 Jun 2011 15:21:07 +0000
Subject: [issue12348] case sensitivness  in packaging.pypi.simple.Crawler
In-Reply-To: <1308237667.78.0.20758863265.issue12348@psf.upfronthosting.co.za>
Message-ID: <1308237667.78.0.20758863265.issue12348@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

the PyPI server deals with the package names case issue: if you get webob, it'll find WebOb.

That's not true for mirrors, so we need to fallback to the global index when "webob" is not found under simple/webob/, and look for the name with a different case.

----------
messages: 138449
nosy: alexis, tarek
priority: high
severity: normal
status: open
title: case sensitivness  in packaging.pypi.simple.Crawler
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12348>
_______________________________________

From report at bugs.python.org  Thu Jun 16 17:22:27 2011
From: report at bugs.python.org (ysj.ray)
Date: Thu, 16 Jun 2011 15:22:27 +0000
Subject: [issue9302] distutils API Reference: setup() and Extension
	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1308237747.48.0.0888509013011.issue9302@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

> FYI, in one packaging doc I added one note instead of changing each cell: http://docs.python.org/dev/library/packaging.compiler#id6


I like this solution, it seems more concise and to the point. With this the doc need only one change:


--- a/Doc/distutils/apiref.rst	Fri Apr 29 14:07:28 2011 +0800
+++ b/Doc/distutils/apiref.rst	Thu Jun 16 23:15:12 2011 +0800
@@ -85,15 +85,15 @@
    | *script_args*      | Arguments to supply to the     | a list of strings                                           |
    |                    | setup script                   |                                                             |
    +--------------------+--------------------------------+-------------------------------------------------------------+
-   | *options*          | default options for the setup  | a string                                                    |
+   | *options*          | default options for the setup  | a dictionary                                                |
    |                    | script                         |                                                             |
    +--------------------+--------------------------------+-------------------------------------------------------------+

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9302>
_______________________________________

From report at bugs.python.org  Thu Jun 16 17:26:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Jun 2011 15:26:22 +0000
Subject: [issue9302] distutils API Reference: setup() and Extension
	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1308237982.11.0.679795501898.issue9302@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your feedback.  My patch assumes that people will understand that an argument that has a plural name (like macros) can?t be a string but a list of strings; I don?t know if relying on this inference is better than your initial patch.  An alternate style that I saw somewhere is to use ?[str]? to describe a list of strings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9302>
_______________________________________

From report at bugs.python.org  Thu Jun 16 17:27:57 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 16 Jun 2011 15:27:57 +0000
Subject: [issue12348] case sensitivness  in packaging.pypi.simple.Crawler
In-Reply-To: <1308237667.78.0.20758863265.issue12348@psf.upfronthosting.co.za>
Message-ID: <1308238077.55.0.260223091169.issue12348@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

see also http://mail.python.org/pipermail/catalog-sig/2011-June/003793.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12348>
_______________________________________

From report at bugs.python.org  Thu Jun 16 17:28:30 2011
From: report at bugs.python.org (higery)
Date: Thu, 16 Jun 2011 15:28:30 +0000
Subject: [issue12344] A kind of 'reinitialize_command' function which can
	initialize a command with key-value pair should be added for
	Command class
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1308238110.21.0.97698094937.issue12344@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

But can the get_reinitialized_command function reinitialize a command with a key-value pair? e.g. reinitialize_command('build_ext', inplace=1)

BTW,how to set the repository URI?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Thu Jun 16 17:32:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Jun 2011 15:32:48 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1308238368.89.0.299073554313.issue12344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> But can the get_reinitialized_command function reinitialize a command
> with a key-value pair?
No, that?s why I did not close this report but asked you if you could make a patch to update this method.

> BTW,how to set the repository URI?
If there is no way to edit the repo, then just add another one.

----------
assignee: tarek -> eric.araujo
title: A kind of 'reinitialize_command' function which can initialize a command with key-value pair should be added for Command class -> Add **kwargs to get_reinitialized_command

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Thu Jun 16 17:46:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Jun 2011 15:46:46 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1308234862.44.0.262405628185.issue12328@psf.upfronthosting.co.za>
Message-ID: <1308239190.3643.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Hmm, it seems to me that it should be done in _poll() instead. 
> > Otherwise, recv() will not be interruptible, will it?
> 
> Or maybe WaitForMultipleObjects() should be changed to also wait on
> sigint_event if called by the main thread.

Indeed, this may be even better.

> If it is an auto-reset event then we must worry about a non-main
> thread stealing the event.  Maybe _PyOS_SigintEvent() should return
> NULL if called by a non-main thread, and be documented with a loud
> usage warning.

You are right, we need a manual reset *or* we must ensure that every
user of _PyOS_SigintEvent only does so from the main thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Thu Jun 16 17:58:39 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 16 Jun 2011 15:58:39 +0000
Subject: [issue12341] Some additions to .hgignore
In-Reply-To: <1308156137.45.0.893152397766.issue12341@psf.upfronthosting.co.za>
Message-ID: <1308239919.81.0.712806298364.issue12341@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Awesome, in a 3 line patch I managed to add an error... nice :)

----------
Added file: http://bugs.python.org/file22378/hgignore_additions-default-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12341>
_______________________________________

From report at bugs.python.org  Thu Jun 16 18:01:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jun 2011 16:01:12 +0000
Subject: [issue9302] distutils API Reference: setup() and Extension
	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1308240072.63.0.218628648738.issue9302@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I would not read [str] as implying a list of strings, FWIW.  Nor would I assume a plural option meant a list if the text says "a string".  But I'm just a bystander here and haven't even looked the docs you guys are updating :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9302>
_______________________________________

From report at bugs.python.org  Thu Jun 16 18:11:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Jun 2011 16:11:51 +0000
Subject: [issue9302] distutils API Reference: setup() and Extension
	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1308240711.91.0.0664543632489.issue9302@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Nor would I assume a plural option meant a list if the text says "a string".

Especially in distutils code where we can get space-separated or comma-separated values from the command line or config files.  I?m in favor of using explicit ?list of strings? wording now.  ysj.ray, I understand from the ?Done? comments on the review page that you have an updated patch somewhere; please upload and I?ll commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9302>
_______________________________________

From report at bugs.python.org  Thu Jun 16 18:15:45 2011
From: report at bugs.python.org (higery)
Date: Thu, 16 Jun 2011 16:15:45 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1308240945.71.0.619721221215.issue12344@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

>No, that?s why I did not close this report but asked you if you could make a patch to update this method.

OK, I think I can try to fix it later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Thu Jun 16 18:16:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Jun 2011 16:16:18 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1308240978.02.0.113553464614.issue8668@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +Add **kwargs to get_reinitialized_command

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Jun 16 18:29:51 2011
From: report at bugs.python.org (Collin Winter)
Date: Thu, 16 Jun 2011 16:29:51 +0000
Subject: [issue5572] distutils ignores the LIBS configure env var
In-Reply-To: <1238095013.07.0.627782689433.issue5572@psf.upfronthosting.co.za>
Message-ID: <1308241791.38.0.731630195648.issue5572@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

This wasn't so much a feature request as a request for review. I had already implemented the necessary changes and provided a patch.

We found this change necessary when working on Unladen Swallow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5572>
_______________________________________

From report at bugs.python.org  Thu Jun 16 18:33:25 2011
From: report at bugs.python.org (Collin Winter)
Date: Thu, 16 Jun 2011 16:33:25 +0000
Subject: [issue5575] Add env vars for controlling building sqlite,
	hashlib and ssl
In-Reply-To: <1238101680.27.0.350099709898.issue5575@psf.upfronthosting.co.za>
Message-ID: <1308242005.31.0.0888842291225.issue5575@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

I don't know that the variables are Python-specific. We used these variables to build various Python modules statically against the versions of openssl and sqlite maintained in Google's internal third-party repository.

----------
assignee: collinwinter -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5575>
_______________________________________

From report at bugs.python.org  Thu Jun 16 19:33:39 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 16 Jun 2011 17:33:39 +0000
Subject: [issue12341] Some additions to .hgignore
In-Reply-To: <1308156137.45.0.893152397766.issue12341@psf.upfronthosting.co.za>
Message-ID: <1308245619.29.0.918064867409.issue12341@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/issue12341>
_______________________________________

From report at bugs.python.org  Thu Jun 16 19:37:02 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 16 Jun 2011 17:37:02 +0000
Subject: [issue12313] make install misses test dirs for packaging and email
	modules
In-Reply-To: <1307722082.95.0.13819638115.issue12313@psf.upfronthosting.co.za>
Message-ID: <1308245822.65.0.632497710025.issue12313@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Perhaps not in the general case, but I found the missing test_email and test_email/data through running regrtest using an installed Python 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12313>
_______________________________________

From report at bugs.python.org  Thu Jun 16 22:13:08 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 16 Jun 2011 20:13:08 +0000
Subject: [issue12340] Access violation when using the C version of the io
	module
In-Reply-To: <1308152515.03.0.630952257185.issue12340@psf.upfronthosting.co.za>
Message-ID: <1308255188.85.0.634689956595.issue12340@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

As for the "<memory at %p>" string, when _io.BufferedWriter prepares the byte buffer into a PyMemoryView wrapper and passes it into the raw IO object:

    res = PyObject_CallMethodObjArgs(self->raw, _PyIO_str_write, memobj, NULL);

For some reason, memobj.__repr__ is called before being passed to the raw IO's write method.

I can't reproduce this odd behavior using a dumb raw IO that extends _io.RawIOBase. Mimicking what pyserial does, however, reproduces both issues (see attached).

----------
Added file: http://bugs.python.org/file22379/test_bufio.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12340>
_______________________________________

From report at bugs.python.org  Thu Jun 16 22:16:24 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 16 Jun 2011 20:16:24 +0000
Subject: [issue12340] Access violation when using the C version of the io
	module
In-Reply-To: <1308152515.03.0.630952257185.issue12340@psf.upfronthosting.co.za>
Message-ID: <1308255384.52.0.853667005545.issue12340@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Note: Removing threading call (lock acquire, release) would remove the crash, but still triggers the "<memory at %p>" conversion of PyMemoryView.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12340>
_______________________________________

From report at bugs.python.org  Thu Jun 16 22:17:50 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 16 Jun 2011 20:17:50 +0000
Subject: [issue12340] Access violation when using the C version of the io
	module
In-Reply-To: <1308152515.03.0.630952257185.issue12340@psf.upfronthosting.co.za>
Message-ID: <1308255470.92.0.104914525796.issue12340@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


Added file: http://bugs.python.org/file22380/test_bufio_nothreading.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12340>
_______________________________________

From report at bugs.python.org  Thu Jun 16 22:20:26 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 16 Jun 2011 20:20:26 +0000
Subject: [issue12349] Typo in 3.2 "What's New": WGSI / WSGI
In-Reply-To: <1308255626.38.0.351857502668.issue12349@psf.upfronthosting.co.za>
Message-ID: <1308255626.38.0.351857502668.issue12349@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-June/004729.html, here's a patch to correct the WGSI/WSGI typo in 3.2 "What's new" (to be applied in 3.2 and default).

----------
assignee: docs at python
components: Documentation
files: 3.2_whatsnew_WSGI-3.2.patch
keywords: patch
messages: 138465
nosy: docs at python, sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Typo in 3.2 "What's New": WGSI / WSGI
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22381/3.2_whatsnew_WSGI-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12349>
_______________________________________

From report at bugs.python.org  Thu Jun 16 22:25:41 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 16 Jun 2011 20:25:41 +0000
Subject: [issue12340] Access violation when using the C version of the io
	module
In-Reply-To: <1308152515.03.0.630952257185.issue12340@psf.upfronthosting.co.za>
Message-ID: <1308255941.5.0.814327196386.issue12340@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

If `write(self, data)` is expected to receive `data` as a memoryview object, then it's up to pyserial to use `data.tobytes()` instead of `bytes(data)`, though this does not seem to be documented in the io module doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12340>
_______________________________________

From report at bugs.python.org  Thu Jun 16 22:28:47 2011
From: report at bugs.python.org (Lars Wirzenius)
Date: Thu, 16 Jun 2011 20:28:47 +0000
Subject: [issue12350] Improve stat_result.st_blocks and st_blksize
	documentation
In-Reply-To: <1308256127.22.0.581997138097.issue12350@psf.upfronthosting.co.za>
Message-ID: <1308256127.22.0.581997138097.issue12350@psf.upfronthosting.co.za>


New submission from Lars Wirzenius <liw at liw.fi>:

Attached patch adds a few words to the os.stat documentation for the st_blocks and st_blksize fields to clarify them.

----------
assignee: docs at python
components: Documentation
files: stat_result.patch
keywords: patch
messages: 138467
nosy: docs at python, liw
priority: normal
severity: normal
status: open
title: Improve stat_result.st_blocks and st_blksize documentation
versions: Python 2.7
Added file: http://bugs.python.org/file22382/stat_result.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12350>
_______________________________________

From report at bugs.python.org  Thu Jun 16 22:42:32 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jun 2011 20:42:32 +0000
Subject: [issue12350] Improve stat_result.st_blocks and st_blksize
	documentation
In-Reply-To: <1308256127.22.0.581997138097.issue12350@psf.upfronthosting.co.za>
Message-ID: <1308256952.91.0.218385295755.issue12350@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looks good for linux.  Do you have a posix reference that confirms this interpretation?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12350>
_______________________________________

From report at bugs.python.org  Thu Jun 16 22:44:54 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jun 2011 20:44:54 +0000
Subject: [issue12313] make install misses test dirs for packaging and email
	modules
In-Reply-To: <1307722082.95.0.13819638115.issue12313@psf.upfronthosting.co.za>
Message-ID: <1308257094.57.0.394897683327.issue12313@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah.  I wouldn't have expected that.  For my information, what was the error you got?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12313>
_______________________________________

From report at bugs.python.org  Thu Jun 16 22:49:57 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 16 Jun 2011 20:49:57 +0000
Subject: [issue12351] Update URL for pycrypto project
In-Reply-To: <1308257397.7.0.688141477172.issue12351@psf.upfronthosting.co.za>
Message-ID: <1308257397.7.0.688141477172.issue12351@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-June/004728.html, here's a patch (appliable on 2.7, 3.1, 3.2 and default) to update the pycrypto URL to its new home.

----------
assignee: docs at python
components: Documentation
files: pycrypto_new_url-2.7.patch
keywords: patch
messages: 138470
nosy: docs at python, sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Update URL for pycrypto project
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22383/pycrypto_new_url-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12351>
_______________________________________

From report at bugs.python.org  Thu Jun 16 23:05:56 2011
From: report at bugs.python.org (Lars Wirzenius)
Date: Thu, 16 Jun 2011 21:05:56 +0000
Subject: [issue12350] Improve stat_result.st_blocks and st_blksize
	documentation
In-Reply-To: <1308256127.22.0.581997138097.issue12350@psf.upfronthosting.co.za>
Message-ID: <1308258356.31.0.134218079649.issue12350@psf.upfronthosting.co.za>


Lars Wirzenius <liw at liw.fi> added the comment:

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html says "A file system-specific preferred I/O block size for this object. In some file system types, this may vary from file to file.", which says essentially the same as the Linux stat(2) manpage from which I copied the extra words.

The same page claims that st_blocks may use other units than 512 byte blocks, but that seems to be quite rare. GNU coreutils sources claim HP-UX and AIX PS/2 have non-512 blocks. Perhaps it would be better to indicate how to find out the block size? (Since st_blksize is not it, but that's an easy assumption to make.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12350>
_______________________________________

From report at bugs.python.org  Thu Jun 16 23:07:32 2011
From: report at bugs.python.org (David Watson)
Date: Thu, 16 Jun 2011 21:07:32 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated
	AF_UNIX	addresses
In-Reply-To: <1307918255.48.0.510314783448.issue8372@psf.upfronthosting.co.za>
Message-ID: <20110616210724.GA15597@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

On Sun 12 Jun 2011, Charles-Fran??ois Natali wrote:

> The patches look good to me, except that instead of passing
> (addrlen > buflen) ? buflen : addrlen
> as addrlen argument every time makesockaddr is called, I'd
> prefer if this min was done inside makesockaddr itself,
> i.e. perform min(addrlen, sizeof(struct sockaddr_un)) in the
> AF_UNIX switch case (especially since addrlen is only used for
> AF_UNIX).

Actually, I think it should be clamped at the top of the
function, since the branch for unknown address families ought to
use the length as well (it doesn't, but that's a separate issue).
I'm attaching new patches to do the check in makesockaddr(),
which also change the length parameters from int to socklen_t, in
case the OS returns a really huge value.

I'm also attaching new return-unterminated patches to handle the
possibility that addrlen is unsigned (socklen_t may be unsigned,
and addrlen *is* now unsigned in 3.x).  This entailed specifying
what to do if addrlen < offsetof(struct sockaddr_un, sun_path),
i.e. if the address is truncated at least one byte before the
start of sun_path.

This may well never happen (Python's existing code would raise
SystemError if it did, due to calling
PyString_FromStringAndSize() with a negative length), but I've
made the new patches return None if it does, as None is already
returned if addrlen is 0.  As another precedent of sorts, Linux
currently returns None (i.e. addrlen = 0) when receiving a
datagram from an unbound Unix socket, despite returning an empty
string (i.e. addrlen = offsetof(..., sun_path)) for the same
unbound address in other situations.

(I think the decoders for other address families should also
return None if addrlen is less than the size of the appropriate
struct, but again, that's a separate issue.)

Also, I noticed that on Linux, Python 3.x currently returns empty
addresses as bytes objects rather than strings, whereas the
patches I've provided make it return strings.  In case this
change isn't acceptable for the 3.x maintenance branches, I'm
attaching return-unterminated-3.x-maint-new.diff which still
returns them as bytes (on Linux only).

To sum up the patch order:

2.x:
linux-pass-unterminated-4spc.diff
test-2.x-new.diff
return-unterminated-2.x-new.diff
addrlen-makesockaddr-2.x.diff (or addrlen-2.x-4spc.diff)

3.2:
linux-pass-unterminated-4spc.diff
test-3.x-new.diff
return-unterminated-3.x-maint-new.diff
addrlen-makesockaddr-3.x.diff (or addrlen-3.x-4spc.diff)

default:
linux-pass-unterminated-4spc.diff
test-3.x-new.diff
return-unterminated-3.x-trunk-new.diff
addrlen-makesockaddr-3.x.diff (or addrlen-3.x-4spc.diff)

----------
Added file: http://bugs.python.org/file22384/addrlen-makesockaddr-2.x.diff
Added file: http://bugs.python.org/file22385/addrlen-makesockaddr-3.x.diff
Added file: http://bugs.python.org/file22386/return-unterminated-2.x-new.diff
Added file: http://bugs.python.org/file22387/return-unterminated-3.x-maint-new.diff
Added file: http://bugs.python.org/file22388/return-unterminated-3.x-trunk-new.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________
-------------- next part --------------
If accept(), etc. return a larger addrlen than was supplied,
ignore it and use the original buffer length.

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -969,13 +969,22 @@ makebdaddr(bdaddr_t *bdaddr)
 
 /*ARGSUSED*/
 static PyObject *
-makesockaddr(int sockfd, struct sockaddr *addr, int addrlen, int proto)
+makesockaddr(int sockfd, struct sockaddr *addr, socklen_t addrlen,
+             socklen_t buflen, int proto)
 {
     if (addrlen == 0) {
         /* No address -- may be recvfrom() from known socket */
         Py_INCREF(Py_None);
         return Py_None;
     }
+    /* buflen is the length of the buffer containing the address, and
+       addrlen is either the same, or is the length returned by the OS
+       after writing an address into the buffer.  Some systems return
+       the length they would have written if there had been space
+       (e.g. when an oversized AF_UNIX address has its sun_path
+       truncated). */
+    if (addrlen > buflen)
+        addrlen = buflen;
 
 #ifdef __BEOS__
     /* XXX: BeOS version of accept() doesn't set family correctly */
@@ -1632,6 +1641,7 @@ sock_accept(PySocketSockObject *s)
     sock_addr_t addrbuf;
     SOCKET_T newfd;
     socklen_t addrlen;
+    socklen_t buflen;
     PyObject *sock = NULL;
     PyObject *addr = NULL;
     PyObject *res = NULL;
@@ -1639,6 +1649,7 @@ sock_accept(PySocketSockObject *s)
 
     if (!getsockaddrlen(s, &addrlen))
         return NULL;
+    buflen = addrlen;
     memset(&addrbuf, 0, addrlen);
 
 #ifdef MS_WINDOWS
@@ -1680,7 +1691,7 @@ sock_accept(PySocketSockObject *s)
         goto finally;
     }
     addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf),
-                        addrlen, s->sock_proto);
+                        addrlen, buflen, s->sock_proto);
     if (addr == NULL)
         goto finally;
 
@@ -2178,16 +2189,18 @@ sock_getsockname(PySocketSockObject *s)
     sock_addr_t addrbuf;
     int res;
     socklen_t addrlen;
+    socklen_t buflen;
 
     if (!getsockaddrlen(s, &addrlen))
         return NULL;
+    buflen = addrlen;
     memset(&addrbuf, 0, addrlen);
     Py_BEGIN_ALLOW_THREADS
     res = getsockname(s->sock_fd, SAS2SA(&addrbuf), &addrlen);
     Py_END_ALLOW_THREADS
     if (res < 0)
         return s->errorhandler();
-    return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen,
+    return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, buflen,
                         s->sock_proto);
 }
 
@@ -2207,16 +2220,18 @@ sock_getpeername(PySocketSockObject *s)
     sock_addr_t addrbuf;
     int res;
     socklen_t addrlen;
+    socklen_t buflen;
 
     if (!getsockaddrlen(s, &addrlen))
         return NULL;
+    buflen = addrlen;
     memset(&addrbuf, 0, addrlen);
     Py_BEGIN_ALLOW_THREADS
     res = getpeername(s->sock_fd, SAS2SA(&addrbuf), &addrlen);
     Py_END_ALLOW_THREADS
     if (res < 0)
         return s->errorhandler();
-    return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen,
+    return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, buflen,
                         s->sock_proto);
 }
 
@@ -2542,11 +2557,13 @@ sock_recvfrom_guts(PySocketSockObject *s
     int timeout;
     ssize_t n = -1;
     socklen_t addrlen;
+    socklen_t buflen;
 
     *addr = NULL;
 
     if (!getsockaddrlen(s, &addrlen))
         return -1;
+    buflen = addrlen;
 
     if (!IS_SELECTABLE(s)) {
         select_error();
@@ -2582,7 +2599,7 @@ sock_recvfrom_guts(PySocketSockObject *s
     }
 
     if (!(*addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf),
-                               addrlen, s->sock_proto)))
+                               addrlen, buflen, s->sock_proto)))
         return -1;
 
     return n;
@@ -4114,7 +4131,8 @@ socket_getaddrinfo(PyObject *self, PyObj
         goto err;
     for (res = res0; res; res = res->ai_next) {
         PyObject *addr =
-            makesockaddr(-1, res->ai_addr, res->ai_addrlen, protocol);
+            makesockaddr(-1, res->ai_addr, res->ai_addrlen, res->ai_addrlen,
+                         protocol);
         if (addr == NULL)
             goto err;
         single = Py_BuildValue("iiisO", res->ai_family,
-------------- next part --------------
If accept(), etc. return a larger addrlen than was supplied,
ignore it and use the original buffer length.

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -1026,13 +1026,22 @@ makebdaddr(bdaddr_t *bdaddr)
 
 /*ARGSUSED*/
 static PyObject *
-makesockaddr(SOCKET_T sockfd, struct sockaddr *addr, size_t addrlen, int proto)
+makesockaddr(SOCKET_T sockfd, struct sockaddr *addr, socklen_t addrlen,
+             socklen_t buflen, int proto)
 {
     if (addrlen == 0) {
         /* No address -- may be recvfrom() from known socket */
         Py_INCREF(Py_None);
         return Py_None;
     }
+    /* buflen is the length of the buffer containing the address, and
+       addrlen is either the same, or is the length returned by the OS
+       after writing an address into the buffer.  Some systems return
+       the length they would have written if there had been space
+       (e.g. when an oversized AF_UNIX address has its sun_path
+       truncated). */
+    if (addrlen > buflen)
+        addrlen = buflen;
 
     switch (addr->sa_family) {
 
@@ -1684,12 +1693,14 @@ sock_accept(PySocketSockObject *s)
     sock_addr_t addrbuf;
     SOCKET_T newfd = INVALID_SOCKET;
     socklen_t addrlen;
+    socklen_t buflen;
     PyObject *sock = NULL;
     PyObject *addr = NULL;
     PyObject *res = NULL;
     int timeout;
     if (!getsockaddrlen(s, &addrlen))
         return NULL;
+    buflen = addrlen;
     memset(&addrbuf, 0, addrlen);
 
     if (!IS_SELECTABLE(s))
@@ -1719,7 +1730,7 @@ sock_accept(PySocketSockObject *s)
     }
 
     addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf),
-                        addrlen, s->sock_proto);
+                        addrlen, buflen, s->sock_proto);
     if (addr == NULL)
         goto finally;
 
@@ -2169,16 +2180,18 @@ sock_getsockname(PySocketSockObject *s)
     sock_addr_t addrbuf;
     int res;
     socklen_t addrlen;
+    socklen_t buflen;
 
     if (!getsockaddrlen(s, &addrlen))
         return NULL;
+    buflen = addrlen;
     memset(&addrbuf, 0, addrlen);
     Py_BEGIN_ALLOW_THREADS
     res = getsockname(s->sock_fd, SAS2SA(&addrbuf), &addrlen);
     Py_END_ALLOW_THREADS
     if (res < 0)
         return s->errorhandler();
-    return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen,
+    return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, buflen,
                         s->sock_proto);
 }
 
@@ -2198,16 +2211,18 @@ sock_getpeername(PySocketSockObject *s)
     sock_addr_t addrbuf;
     int res;
     socklen_t addrlen;
+    socklen_t buflen;
 
     if (!getsockaddrlen(s, &addrlen))
         return NULL;
+    buflen = addrlen;
     memset(&addrbuf, 0, addrlen);
     Py_BEGIN_ALLOW_THREADS
     res = getpeername(s->sock_fd, SAS2SA(&addrbuf), &addrlen);
     Py_END_ALLOW_THREADS
     if (res < 0)
         return s->errorhandler();
-    return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen,
+    return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, buflen,
                         s->sock_proto);
 }
 
@@ -2476,11 +2491,13 @@ sock_recvfrom_guts(PySocketSockObject *s
     int timeout;
     Py_ssize_t n = -1;
     socklen_t addrlen;
+    socklen_t buflen;
 
     *addr = NULL;
 
     if (!getsockaddrlen(s, &addrlen))
         return -1;
+    buflen = addrlen;
 
     if (!IS_SELECTABLE(s)) {
         select_error();
@@ -2518,7 +2535,7 @@ sock_recvfrom_guts(PySocketSockObject *s
     }
 
     if (!(*addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf),
-                               addrlen, s->sock_proto)))
+                               addrlen, buflen, s->sock_proto)))
         return -1;
 
     return n;
@@ -4110,7 +4127,8 @@ socket_getaddrinfo(PyObject *self, PyObj
     for (res = res0; res; res = res->ai_next) {
         PyObject *single;
         PyObject *addr =
-            makesockaddr(-1, res->ai_addr, res->ai_addrlen, protocol);
+            makesockaddr(-1, res->ai_addr, res->ai_addrlen, res->ai_addrlen,
+                         protocol);
         if (addr == NULL)
             goto err;
         single = Py_BuildValue("iiisO", res->ai_family,
-------------- next part --------------
When parsing sockaddr_un structures returned by accept(), etc.,
only examine bytes up to supplied addrlen and do not require null
termination.

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -1000,19 +1000,27 @@ makesockaddr(int sockfd, struct sockaddr
 #if defined(AF_UNIX)
     case AF_UNIX:
     {
+        Py_ssize_t len, splen;
         struct sockaddr_un *a = (struct sockaddr_un *) addr;
+
+        if (addrlen < offsetof(struct sockaddr_un, sun_path))
+            Py_RETURN_NONE;
+        else
+            splen = addrlen - offsetof(struct sockaddr_un, sun_path);
 #ifdef linux
-        if (a->sun_path[0] == 0) {  /* Linux abstract namespace */
-            addrlen -= offsetof(struct sockaddr_un, sun_path);
-            return PyString_FromStringAndSize(a->sun_path,
-                                              addrlen);
+        if (splen > 0 && a->sun_path[0] == 0) {
+            /* Linux abstract namespace */
+            len = splen;
         }
         else
 #endif /* linux */
         {
-            /* regular NULL-terminated string */
-            return PyString_FromString(a->sun_path);
+            /* Path text can occupy all of sun_path[], and therefore
+               lack null termination */
+            for (len = 0; len < splen && a->sun_path[len] != 0; len++)
+                ;
         }
+        return PyString_FromStringAndSize(a->sun_path, len);
     }
 #endif /* AF_UNIX */
 
-------------- next part --------------
When parsing sockaddr_un structures returned by accept(), etc.,
only examine bytes up to supplied addrlen and do not require null
termination.

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -1038,18 +1038,28 @@ makesockaddr(SOCKET_T sockfd, struct soc
 #if defined(AF_UNIX)
     case AF_UNIX:
     {
+        Py_ssize_t len, splen;
         struct sockaddr_un *a = (struct sockaddr_un *) addr;
+
+        if (addrlen < offsetof(struct sockaddr_un, sun_path))
+            Py_RETURN_NONE;
+        else
+            splen = addrlen - offsetof(struct sockaddr_un, sun_path);
 #ifdef linux
-        if (a->sun_path[0] == 0) {  /* Linux abstract namespace */
-            addrlen -= offsetof(struct sockaddr_un, sun_path);
-            return PyBytes_FromStringAndSize(a->sun_path, addrlen);
+        /* Backwards compatibility: return empty addresses as bytes */
+        if (splen == 0 || (splen > 0 && a->sun_path[0] == 0)) {
+            /* Linux abstract namespace */
+            return PyBytes_FromStringAndSize(a->sun_path, splen);
         }
         else
 #endif /* linux */
         {
-            /* regular NULL-terminated string */
-            return PyUnicode_FromString(a->sun_path);
+            /* Path text can occupy all of sun_path[], and therefore
+               lack null termination */
+            for (len = 0; len < splen && a->sun_path[len] != 0; len++)
+                ;
         }
+        return PyUnicode_FromStringAndSize(a->sun_path, len);
     }
 #endif /* AF_UNIX */
 
-------------- next part --------------
When parsing sockaddr_un structures returned by accept(), etc.,
only examine bytes up to supplied addrlen and do not require null
termination.

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -1052,18 +1052,27 @@ makesockaddr(SOCKET_T sockfd, struct soc
 #if defined(AF_UNIX)
     case AF_UNIX:
     {
+        Py_ssize_t len, splen;
         struct sockaddr_un *a = (struct sockaddr_un *) addr;
+
+        if (addrlen < offsetof(struct sockaddr_un, sun_path))
+            Py_RETURN_NONE;
+        else
+            splen = addrlen - offsetof(struct sockaddr_un, sun_path);
 #ifdef linux
-        if (a->sun_path[0] == 0) {  /* Linux abstract namespace */
-            addrlen -= offsetof(struct sockaddr_un, sun_path);
-            return PyBytes_FromStringAndSize(a->sun_path, addrlen);
+        if (splen > 0 && a->sun_path[0] == 0) {
+            /* Linux abstract namespace */
+            return PyBytes_FromStringAndSize(a->sun_path, splen);
         }
         else
 #endif /* linux */
         {
-            /* regular NULL-terminated string */
-            return PyUnicode_FromString(a->sun_path);
+            /* Path text can occupy all of sun_path[], and therefore
+               lack null termination */
+            for (len = 0; len < splen && a->sun_path[len] != 0; len++)
+                ;
         }
+        return PyUnicode_FromStringAndSize(a->sun_path, len);
     }
 #endif /* AF_UNIX */
 

From report at bugs.python.org  Thu Jun 16 23:24:02 2011
From: report at bugs.python.org (John Whitney)
Date: Thu, 16 Jun 2011 21:24:02 +0000
Subject: [issue1602133] non-framework built python fails to define environ
	properly
Message-ID: <1308259442.53.0.693286264043.issue1602133@psf.upfronthosting.co.za>


John Whitney <jjwhitney at gmail.com> added the comment:

I have also been experiencing this problem with _environ (using the latest Python - 2.7.2), and this patch works great. I'd love to see it committed so that I don't have to patch Python.

----------
nosy: +jjw

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602133>
_______________________________________

From report at bugs.python.org  Thu Jun 16 23:38:43 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jun 2011 21:38:43 +0000
Subject: [issue12350] Improve stat_result.st_blocks and st_blksize
	documentation
In-Reply-To: <1308256127.22.0.581997138097.issue12350@psf.upfronthosting.co.za>
Message-ID: <1308260323.79.0.0350542753928.issue12350@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, bingo.  That was what was tickling at my memory but I couldn't remember what the exact issue was I was recalling.  I forget what I was doing where that mattered, but as I vaguely remember it there is no portable way to find out what blocksize st_blocks is in.  Or at least not one that is currently exposed from Python.  I could be remembering wrong, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12350>
_______________________________________

From report at bugs.python.org  Thu Jun 16 23:44:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jun 2011 21:44:03 +0000
Subject: [issue12350] Improve stat_result.st_blocks and st_blksize
	documentation
In-Reply-To: <1308256127.22.0.581997138097.issue12350@psf.upfronthosting.co.za>
Message-ID: <1308260643.74.0.742186643914.issue12350@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, found it: Issue 10016.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12350>
_______________________________________

From report at bugs.python.org  Thu Jun 16 23:44:32 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jun 2011 21:44:32 +0000
Subject: [issue12350] Improve stat_result.st_blocks and st_blksize
	documentation
In-Reply-To: <1308256127.22.0.581997138097.issue12350@psf.upfronthosting.co.za>
Message-ID: <1308260672.13.0.440249271003.issue12350@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12350>
_______________________________________

From report at bugs.python.org  Fri Jun 17 00:59:09 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jun 2011 22:59:09 +0000
Subject: [issue9344] please add posix.getgrouplist()
In-Reply-To: <1279890657.77.0.804697326433.issue9344@psf.upfronthosting.co.za>
Message-ID: <1308265149.38.0.315105488948.issue9344@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Actually, when it is a feature request rather than a bug fix we usually use 'accepted'.  It doesn't matter a whole lot, though.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9344>
_______________________________________

From report at bugs.python.org  Fri Jun 17 01:00:21 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jun 2011 23:00:21 +0000
Subject: [issue8887] "pydoc str" works but not "pydoc str.translate"
In-Reply-To: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>
Message-ID: <1308265221.73.0.502941305456.issue8887@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: ?pydoc str? works but not ?pydoc str.translate? -> "pydoc str" works but not "pydoc str.translate"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8887>
_______________________________________

From report at bugs.python.org  Fri Jun 17 01:09:05 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 16 Jun 2011 23:09:05 +0000
Subject: [issue12313] make install misses test dirs for packaging and email
	modules
In-Reply-To: <1308257094.57.0.394897683327.issue12313@psf.upfronthosting.co.za>
Message-ID: <507321.99454.qm@web25808.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> R. David Murray <rdmurray at bitdance.com> added the  comment:

> 
> Ah.  I wouldn't have expected that.  For my  information, what was the error 
>you  got?

[ 99/356] test_email
test test_email crashed -- Traceback (most recent call last):
  File "regrtest.py", line 1036, in runtest_inner
ImportError: No module named 'test_email'

>From the full test results at

https://gist.github.com/1022705/45fa6992c25197a3c9f6281fc645da94dcc5feae

N.B. I have now fixed the error in my fork, you can see the change I made here:

https://bitbucket.org/vinay.sajip/pythonv/compare/..mirror/cpython#chg-Makefile.pre.in

Regards,

Vinay Sajip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12313>
_______________________________________

From report at bugs.python.org  Fri Jun 17 01:09:47 2011
From: report at bugs.python.org (Simon Baird)
Date: Thu, 16 Jun 2011 23:09:47 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1308265787.16.0.271515623576.issue12345@psf.upfronthosting.co.za>


Changes by Simon Baird <simon.baird at gmail.com>:


----------
nosy: +sbaird

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Fri Jun 17 01:42:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jun 2011 23:42:34 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1308267754.97.0.955017346382.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 5 fixes the encode/decode flags on Windows XP. The codecs give different result on XP and Seven in some cases:

Seven:

- b'\x81\x00abc'.decode('cp932', 'replace') returns '\u30fb\x00abc'
- '\udc80'.encode(CP_UTF8, 'strict') raises UnicodeEncodeError
- b'[\xed\xb2\x80]'.decode(CP_UTF8, 'strict') raises UnicodeEncodeError
- b'[\xed\xb2\x80]'.decode(CP_UTF8, 'ignore') returns '[]'
- b'[\xed\xb2\x80]'.decode(CP_UTF8, 'replace') returns '[\ufffd\ufffd\ufffd]'

XP:

- b'\x81\x00abc'.decode('cp932', 'replace') returns '\x00\x00abc'
- '\udc80'.encode(CP_UTF8, 'strict') returns b'\xed\xb2\x80'
- b'[\xed\xb2\x80]'.decode(CP_UTF8, 'strict') returns '[\udc80]'

These differences come from Windows codecs.

----------
Added file: http://bugs.python.org/file22389/mbcs5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Fri Jun 17 01:48:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 16 Jun 2011 23:48:18 +0000
Subject: [issue12351] Update URL for pycrypto project
In-Reply-To: <1308257397.7.0.688141477172.issue12351@psf.upfronthosting.co.za>
Message-ID: <E1QXMIL-0003Mk-AR@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0cb49ca95109 by Benjamin Peterson in branch '2.7':
update link to pycrypto (closes #12351)
http://hg.python.org/cpython/rev/0cb49ca95109

New changeset 4d465cef3257 by Benjamin Peterson in branch '3.2':
update link to pycrypto (closes #12351)
http://hg.python.org/cpython/rev/4d465cef3257

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12351>
_______________________________________

From report at bugs.python.org  Fri Jun 17 01:51:37 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 16 Jun 2011 23:51:37 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1308268297.4.0.0514915174467.issue12281@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What is the use of these code_page_encode() functions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Fri Jun 17 01:52:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jun 2011 23:52:09 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1308268329.75.0.259268639768.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

TODO: add more tests

CP_UTF8:

        if self.vista_or_later:
            tests.append(('\udc80', 'strict', None))
            tests.append(('\udc80', 'ignore', b''))
            tests.append(('\udc80', 'replace', b'\xef\xbf\xbd'))
        else:
            tests.append(('\udc80', 'strict', b'\xed\xb2\x80'))

cp1252:

            ('\u0141', 'strict', None),
            ('\u0141', 'ignore', b''),
            ('\u0141', 'replace', b'L'),

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Fri Jun 17 02:15:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jun 2011 00:15:08 +0000
Subject: [issue12320] test_packaging failures
In-Reply-To: <1307886896.56.0.892165985484.issue12320@psf.upfronthosting.co.za>
Message-ID: <1308269708.3.0.228637578072.issue12320@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also:
http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/1516
http://www.python.org/dev/buildbot/all/builders/sparc%20solaris10%20gcc%203.x/builds/3276

There are many OSError(22, 'Invalid argument: ...') errors on rmdir(). Example:

======================================================================
ERROR: test_cfg_to_args (packaging.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/packaging/tests/test_util.py", line 147, in tearDown
    super(UtilTestCase, self).tearDown()
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/packaging/tests/support.py", line 225, in tearDown
    super(EnvironRestorer, self).tearDown()
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/packaging/tests/support.py", line 128, in tearDown
    shutil.rmtree(self._basetempdir, os.name in ('nt', 'cygwin'))
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/shutil.py", line 278, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/shutil.py", line 287, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/shutil.py", line 285, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmp2le6q5/tmpg5rur7'

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12320>
_______________________________________

From report at bugs.python.org  Fri Jun 17 02:31:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jun 2011 00:31:07 +0000
Subject: [issue12313] make install misses test dirs for packaging and email
	modules
In-Reply-To: <1307722082.95.0.13819638115.issue12313@psf.upfronthosting.co.za>
Message-ID: <1308270667.9.0.783025710979.issue12313@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, now I'm really confused.  I tried to reproduce this by installing from my checkout into a work dir, and then running regrtest using that installed python, and discovered that test_email and its data directory got copied by the installation process.  (There were test failures, so I'll have to work on that...)  This is without any mention of test_email in the Makefile I used to do the 'make install'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12313>
_______________________________________

From report at bugs.python.org  Fri Jun 17 02:35:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jun 2011 00:35:35 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1308268297.4.0.0514915174467.issue12281@psf.upfronthosting.co.za>
Message-ID: <1308270934.11601.13.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> What is the use of these code_page_encode() functions?

I wrote them to be able to write tests.

We can maybe use them to implement the Python code page codecs using a
custom codec register function: see msg138246. Windows codecs seem to be
less reliable/portable than Python builtin codecs, they behave
differently depending on the Windows version. Windows codecs are maybe
faster, I should (write and) run a benchmark.

My main concern is to fix error handling of the Python mbcs codec.

--

I am also trying to factorize the code in posixmodule.c: I would like to
remove the bytes implementation of each function when a function has two
implementations (bytes and Unicode) only for Windows. The idea is to
decode filenames exactly as Windows do and reuse the Unicode
implementation. I don't know yet how Windows do decode bytes filenames
(especially how it handles undecodable bytes), I suppose that it uses
MultiByteToWideChar using cp=CP_ACP and flags=0.

We may patch os.fsdecode() to handle undecodable bytes like Windows
does. codecs.code_page_decode() would help this specific idea, except
that my current patch doesn't allow to specify directly the flags.
"replace" and "ignore" error handlers don't behave as flags=0, or at
least not in some cases. codecs.code_page_decode() should allow to
specific an error handler *or* the flags (mutual exclusive options).

Example:

def fsdecode(filename):
   if isinstance(filename, bytes):
       return codecs.code_page_decode(codecs.CP_ACP, filename, flags=0)
   elif isinstance(filename, str):
       return filename
   else:
       raise TypeError()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Fri Jun 17 02:57:00 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 17 Jun 2011 00:57:00 +0000
Subject: [issue12313] make install misses test dirs for packaging and email
	modules
In-Reply-To: <1308270667.9.0.783025710979.issue12313@psf.upfronthosting.co.za>
Message-ID: <413625.10232.qm@web25806.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> OK, now I'm really confused.  I tried to reproduce this by  installing from my 
>checkout into a work dir, and then running regrtest using  that installed 
>python, and discovered that test_email and its data directory got  copied by the 
>installation process.  (There were test failures, so I'll  have to work on 
>that...)  This is without any mention of test_email in the  Makefile I used to 
>do the 'make  install'.

That does seem odd. On my pythonv fork (which follows the cpython repo pretty 
closely), the only current failures are test_lib2to3, test_packaging and 
test_sysconfig - all of which failures are already the subject of tickets on the 
tracker. On my system at least, test_email doesn't show up any failures. See the 
latest version of the test log from the Gist link I posted earlier - the comment 
also references the failure tickets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12313>
_______________________________________

From report at bugs.python.org  Fri Jun 17 03:34:35 2011
From: report at bugs.python.org (higery)
Date: Fri, 17 Jun 2011 01:34:35 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1308274475.29.0.26030620023.issue12344@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22390/6b68c2835d6e.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Fri Jun 17 03:54:25 2011
From: report at bugs.python.org (higery)
Date: Fri, 17 Jun 2011 01:54:25 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1308275665.21.0.235540024124.issue12344@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

Not yet tested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Fri Jun 17 04:06:31 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jun 2011 02:06:31 +0000
Subject: [issue12320] test_packaging failures
In-Reply-To: <1307886896.56.0.892165985484.issue12320@psf.upfronthosting.co.za>
Message-ID: <1308276391.88.0.0835380033853.issue12320@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Victor, that failure was already reported in issue 12333.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12320>
_______________________________________

From report at bugs.python.org  Fri Jun 17 04:31:41 2011
From: report at bugs.python.org (ysj.ray)
Date: Fri, 17 Jun 2011 02:31:41 +0000
Subject: [issue9302] distutils API Reference: setup() and Extension
	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1308277901.91.0.197285885034.issue9302@psf.upfronthosting.co.za>


ysj.ray <ysj.ray at gmail.com> added the comment:

> I would not read [str] as implying a list of strings, FWIW.

help() on distutils.extension.Extension gives the parameters description like this:
    ......
    sources: [string]
    ......
    include_dirs: [string]
    ......

So I guess this style can be used as somewhere.


> I?m in favor of using explicit ?list of strings? wording now.  ysj.ray, I understand from the ?Done? comments on the review page that you have an updated patch somewhere; please upload and I?ll commit.


Ok, here is it. Thanks!

----------
Added file: http://bugs.python.org/file22391/issue_9302_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9302>
_______________________________________

From report at bugs.python.org  Fri Jun 17 06:40:00 2011
From: report at bugs.python.org (Derek Wilson)
Date: Fri, 17 Jun 2011 04:40:00 +0000
Subject: [issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
In-Reply-To: <1242668944.28.0.292370665479.issue6056@psf.upfronthosting.co.za>
Message-ID: <1308285600.02.0.43861803235.issue6056@psf.upfronthosting.co.za>


Derek Wilson <jderekwilson at gmail.com> added the comment:

I was wrong about exit behavior of a process that has put to a queue -- it seems to behave as expected. i had been playing with a proxy to a queue rather than a queue (to which, if you put, the process can exit right away because the actual put happens in the process that owns the queue).

I think this works as intended, but lmk. Also, I haven't really played with the tests that much, so that bit could use some review. It hasn't broken anything in any of my real world tests though.

Also, have I mentioned that the multiprocessing module is amazing? Cause it is. I sort of feel like antigravity == multiprocessing ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6056>
_______________________________________

From report at bugs.python.org  Fri Jun 17 07:49:00 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Jun 2011 05:49:00 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1308289740.88.0.84924790494.issue12281@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> I don't know yet how Windows do decode bytes filenames
> (especially how it handles undecodable bytes), 
> I suppose that it uses MultiByteToWideChar using cp=CP_ACP and flags=0.
It's likely, yes.  But you don't need a new codec function for this.
What about something like .decode('mbcs', errors='windows')?

I still don't see the advantage of codecs.code_page_encode().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Fri Jun 17 08:24:58 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 17 Jun 2011 06:24:58 +0000
Subject: [issue12349] Typo in 3.2 "What's New": WGSI / WSGI
In-Reply-To: <1308255626.38.0.351857502668.issue12349@psf.upfronthosting.co.za>
Message-ID: <1308291898.19.0.386056266757.issue12349@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Fixed by Raymond (thanks!) with these commits:

http://hg.python.org/cpython/rev/0fe3b81c7c89
http://hg.python.org/cpython/rev/cf56abd14eef

----------
nosy: +rhettinger
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12349>
_______________________________________

From report at bugs.python.org  Fri Jun 17 12:17:56 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Fri, 17 Jun 2011 10:17:56 +0000
Subject: [issue12346] Python 2.7.2 source code build (release) depends on
	mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1308305876.42.0.919878061086.issue12346@psf.upfronthosting.co.za>


Ralf Schmitt <python-bugs at systemexit.de> added the comment:

trunk configure.in contains code that checks for the existence of a .hg repository.
See rev 435eec7b41f0

----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12346>
_______________________________________

From report at bugs.python.org  Fri Jun 17 12:20:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 17 Jun 2011 10:20:51 +0000
Subject: [issue12333] test_packaging failures under Solaris
In-Reply-To: <1308061607.43.0.119074494077.issue12333@psf.upfronthosting.co.za>
Message-ID: <E1QXWAT-00069E-Uh@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 276530424350 by Victor Stinner in branch 'default':
Issue #12333: restore the previous dir before removing the current directory
http://hg.python.org/cpython/rev/276530424350

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12333>
_______________________________________

From report at bugs.python.org  Fri Jun 17 12:38:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 17 Jun 2011 10:38:34 +0000
Subject: [issue12310] Segfault in test_multiprocessing
In-Reply-To: <1307697113.9.0.00979334615642.issue12310@psf.upfronthosting.co.za>
Message-ID: <E1QXWRd-0007Qp-G7@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e6e7e42efdc2 by Victor Stinner in branch '3.2':
Issue #12310: finalize the old process after _run_after_forkers()
http://hg.python.org/cpython/rev/e6e7e42efdc2

New changeset a73e5c1f57d7 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12310: finalize the old process after _run_after_forkers()
http://hg.python.org/cpython/rev/a73e5c1f57d7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12310>
_______________________________________

From report at bugs.python.org  Fri Jun 17 12:39:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jun 2011 10:39:26 +0000
Subject: [issue12310] Segfault in test_multiprocessing
In-Reply-To: <1307697113.9.0.00979334615642.issue12310@psf.upfronthosting.co.za>
Message-ID: <1308307166.32.0.570100008306.issue12310@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Let's try on "real" buildbots. If the commit fixes the issue on 3.x, I will port the fix to Python 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12310>
_______________________________________

From report at bugs.python.org  Fri Jun 17 12:45:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jun 2011 10:45:31 +0000
Subject: [issue12333] test_packaging failures under Solaris
In-Reply-To: <1308061607.43.0.119074494077.issue12333@psf.upfronthosting.co.za>
Message-ID: <1308307531.19.0.429386018817.issue12333@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

276530424350 fixed the failures on "x86 OpenIndiana 3.x" buildbot.

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12333>
_______________________________________

From report at bugs.python.org  Fri Jun 17 12:54:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jun 2011 10:54:45 +0000
Subject: [issue12342] characters with ord above 65535 fail to display in IDLE
In-Reply-To: <1308171600.34.0.388895530939.issue12342@psf.upfronthosting.co.za>
Message-ID: <1308308085.21.0.102886460925.issue12342@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Instead of
  ValueError: unsupported character
I suggest:
  ValueError: unsupported character (U+10000): Tcl doesn't support characters outside U+0000-U+FFFF range

What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12342>
_______________________________________

From report at bugs.python.org  Fri Jun 17 12:55:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jun 2011 10:55:15 +0000
Subject: [issue12263] punycode codec ignores the error handler argument
In-Reply-To: <1307229378.45.0.142684435058.issue12263@psf.upfronthosting.co.za>
Message-ID: <1308308115.82.0.998260003771.issue12263@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@Martin: Can you review my patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12263>
_______________________________________

From report at bugs.python.org  Fri Jun 17 13:54:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 17 Jun 2011 11:54:30 +0000
Subject: [issue12333] test_packaging failures under Solaris
In-Reply-To: <1308061607.43.0.119074494077.issue12333@psf.upfronthosting.co.za>
Message-ID: <E1QXXd6-0004pu-SE@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6e5a9f16d831 by Victor Stinner in branch 'default':
Issue #12333: close files before removing the directory
http://hg.python.org/cpython/rev/6e5a9f16d831

New changeset 144cea8db9a5 by Victor Stinner in branch 'default':
Issue #12333: run tests on the new module in a subprocess
http://hg.python.org/cpython/rev/144cea8db9a5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12333>
_______________________________________

From report at bugs.python.org  Fri Jun 17 14:02:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 17 Jun 2011 12:02:40 +0000
Subject: [issue12133] ResourceWarning in urllib.request
In-Reply-To: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>
Message-ID: <E1QXXku-0005jF-Uf@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ad6bdfd7dd4b by Victor Stinner in branch '3.2':
Issue #12133: fix a ResourceWarning in urllib.request
http://hg.python.org/cpython/rev/ad6bdfd7dd4b

New changeset 57a98feb508e by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12133: fix a ResourceWarning in urllib.request
http://hg.python.org/cpython/rev/57a98feb508e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12133>
_______________________________________

From report at bugs.python.org  Fri Jun 17 14:06:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 17 Jun 2011 12:06:30 +0000
Subject: [issue12133] ResourceWarning in urllib.request
In-Reply-To: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>
Message-ID: <E1QXXoj-0006Mx-9M@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 18e6ccc332d5 by Victor Stinner in branch '2.7':
Issue #12133: AbstractHTTPHandler.do_open() of urllib.request closes the HTTP
http://hg.python.org/cpython/rev/18e6ccc332d5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12133>
_______________________________________

From report at bugs.python.org  Fri Jun 17 14:07:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jun 2011 12:07:22 +0000
Subject: [issue12133] ResourceWarning in urllib.request
In-Reply-To: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>
Message-ID: <1308312442.28.0.606502174716.issue12133@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tested the patch on Python 3.3: the full test suite pass on Linux. I applied your patch on Python 2.7, 3.2 and 3.3, thanks Ezio.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12133>
_______________________________________

From report at bugs.python.org  Fri Jun 17 14:17:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jun 2011 12:17:51 +0000
Subject: [issue12309] os.environ was modified by test_packaging
In-Reply-To: <1307696523.79.0.913575304812.issue12309@psf.upfronthosting.co.za>
Message-ID: <1308313071.61.0.685737555084.issue12309@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

A patch fixing os.environ warning for test_command_build_ext.py:

diff --git a/Lib/packaging/tests/test_command_build_ext.py b/Lib/packaging/tests/test_command_build_ext.py
--- a/Lib/packaging/tests/test_command_build_ext.py
+++ b/Lib/packaging/tests/test_command_build_ext.py
@@ -20,7 +20,10 @@ def _get_source_filename():
 
 class BuildExtTestCase(support.TempdirManager,
                        support.LoggingCatcher,
+                       support.EnvironRestorer,
                        unittest.TestCase):
+    restore_environ = ['LIB', 'INCLUDE', 'PATH']
+
     def setUp(self):
         # Create a simple test environment
         # Note that we're making changes to sys.path

It is not enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12309>
_______________________________________

From report at bugs.python.org  Fri Jun 17 14:53:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 17 Jun 2011 12:53:40 +0000
Subject: [issue10883] urllib: socket is not closed explicitly
In-Reply-To: <1294698764.05.0.403920474459.issue10883@psf.upfronthosting.co.za>
Message-ID: <E1QXYYM-0001tw-Tz@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ca18f7f35c28 by Victor Stinner in branch '3.2':
Issue #10883: test_urllib2net closes socket explicitly
http://hg.python.org/cpython/rev/ca18f7f35c28

New changeset 6d38060f290c by Victor Stinner in branch 'default':
(Merge 3.2) Issue #10883: test_urllib2net closes socket explicitly
http://hg.python.org/cpython/rev/6d38060f290c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10883>
_______________________________________

From report at bugs.python.org  Fri Jun 17 15:01:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jun 2011 13:01:43 +0000
Subject: [issue10883] urllib: socket is not closed explicitly
In-Reply-To: <1294698764.05.0.403920474459.issue10883@psf.upfronthosting.co.za>
Message-ID: <1308315703.03.0.0511309917379.issue10883@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

ftp_close.patch:
 - (in passive mode) FTP.ntransfercmd() closes explicitly the socket on error: the caller has not access to the socket on error
 - OtherNetworkTests of test_urllib2net clears CacheFTPHandler cache: add a CacheFTPHandler.clear_cache() for that (I didn't document this new method because other methods are also not documented)
 - the last change is the worst one (ugly hack): FTPHandler.ftp_open() changes the close callback of the addclosehook object in ftpwrapper.retrfile(), but not in CacheFTPHandler.

I don't like the implementation of the last change:
 - it adds a protected class attribute
 - ftpwrapper.retrfile() requires an explicit close=True argument: it would be better to use a "reference counter" (or something like that), like socket._io_refs

----------
keywords: +patch
Added file: http://bugs.python.org/file22392/ftp_close.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10883>
_______________________________________

From report at bugs.python.org  Fri Jun 17 15:19:49 2011
From: report at bugs.python.org (greg.ath)
Date: Fri, 17 Jun 2011 13:19:49 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>


New submission from greg.ath <gathanase at gmail.com>:

Hi,

My multithreaded application uses multithreading.Value() to ensure thread-safe operations on shared data.
For unexpected reasons, after some change in my code, the function will consistently hang.

I did a gdb backtrace of the hanging process, and I discovered that the multiprocessing.head.py tries to acquire twice a same non recursive lock.
The first aquire is done in the "malloc" function:
#61 call_function (f=
    Frame 0x13be190, for file /usr/lib/python2.6/multiprocessing/heap.py, line 173, in malloc (self=<Heap(_stop_to_block={}, _lengths=[], _lock=<thread.lock at remote 0x7f00fc770eb8>, _allocated_blocks=set([...

The second aquire is done in the "free" function:
#3  0x00000000004a7c5e in call_function (f=
    Frame 0x1662d50, for file /usr/lib/python2.6/multiprocessing/heap.py, line 155, in free (self=<Heap(_stop_to_block={}, _lengths=[], _lock=<thread.lock at remote 0x7f00fc770eb8>, _allocated_blocks=set([...

I don't understand the link between these two method calls, so I am unable to write an easy script to reproduce the problem. I would say that some garbage collection was done within the malloc, which called the free.


Python 2.6.5
Linux dev 2.6.32-25-server #45-Ubuntu SMP Sat Oct 16 20:06:58 UTC 2010 x86_64 GNU/Linux

----------
components: None
files: gdb_stack.txt
messages: 138506
nosy: greg.ath
priority: normal
severity: normal
status: open
title: multiprocessing.Value() hangs
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file22393/gdb_stack.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Fri Jun 17 15:51:55 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jun 2011 13:51:55 +0000
Subject: [issue12346] Python 2.7.2 source code build (release) depends on
	mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1308318715.72.0.357822373001.issue12346@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That needs to be ported to the other branches, then.

Ezio, on a completely unrelated note, notice what happened to Ralf's reference.  I think the regexes may need to be reordered.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12346>
_______________________________________

From report at bugs.python.org  Fri Jun 17 15:55:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jun 2011 13:55:17 +0000
Subject: [issue9246] os.getcwd() hardcodes max path len
In-Reply-To: <1279023059.26.0.245683093399.issue9246@psf.upfronthosting.co.za>
Message-ID: <1308318917.92.0.660264372365.issue9246@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Simpler patch replacing 1026 constant by MAXPATHLEN. On my Linux box, MAXPATHLEN is 4096 and os.pathconf('/', 'PC_PATH_MAX') returns 4096. I am able to get a path of 4095 bytes using the patch.

----------
Added file: http://bugs.python.org/file22394/os_getcwd_maxpathlen.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9246>
_______________________________________

From report at bugs.python.org  Fri Jun 17 15:58:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jun 2011 13:58:44 +0000
Subject: [issue9246] os.getcwd() hardcodes max path len
In-Reply-To: <1279023059.26.0.245683093399.issue9246@psf.upfronthosting.co.za>
Message-ID: <1308319124.18.0.668070206346.issue9246@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You may use get_current_dir_name() which allocates the memory for us.

I can adapt os_getcwd_buffer-2.patch to support Solaris/OpenBSD, but do we need a dynamic buffer? (do we need to support OS without PATH_MAX)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9246>
_______________________________________

From report at bugs.python.org  Fri Jun 17 16:00:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jun 2011 14:00:06 +0000
Subject: [issue9246] os.getcwd() hardcodes max path len
In-Reply-To: <1279023059.26.0.245683093399.issue9246@psf.upfronthosting.co.za>
Message-ID: <1308319206.87.0.928390526702.issue9246@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

bigpath2.py: script to check the maximum path length of os.getcwd().

----------
Added file: http://bugs.python.org/file22395/bigpath2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9246>
_______________________________________

From report at bugs.python.org  Fri Jun 17 16:10:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jun 2011 14:10:27 +0000
Subject: [issue12310] Segfault in test_multiprocessing
In-Reply-To: <1307697113.9.0.00979334615642.issue12310@psf.upfronthosting.co.za>
Message-ID: <1308319827.87.0.605923209075.issue12310@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_multiprocessing pass with success on PPC Tiger 3.x (and x86 Tiger 3.x, but the segfaults only occurred on PPC), but this issue is a sporadic issue. I close the issue because I hope that it is closed, but reopen it if you still see segfaults on PPC Tiger 3.x.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12310>
_______________________________________

From report at bugs.python.org  Fri Jun 17 16:11:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jun 2011 14:11:47 +0000
Subject: [issue12320] test_packaging failures
In-Reply-To: <1307886896.56.0.892165985484.issue12320@psf.upfronthosting.co.za>
Message-ID: <1308319907.59.0.466615289967.issue12320@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I fixed the issue #12333. I don't see any test_packaging failure anymore, let's close this issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12320>
_______________________________________

From report at bugs.python.org  Fri Jun 17 17:04:06 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 17 Jun 2011 15:04:06 +0000
Subject: [issue9246] os.getcwd() hardcodes max path len
In-Reply-To: <1308319124.18.0.668070206346.issue9246@psf.upfronthosting.co.za>
Message-ID: <4DFB6CE3.3050501@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I can adapt os_getcwd_buffer-2.patch to support Solaris/OpenBSD, but
> do we need a dynamic buffer? (do we need to support OS without
> PATH_MAX)

>From a practicality point of view, we need to make no change at all:
nobody sane ever has a current working directory path of more than
1000 characters. Even if people have very long path names, they
don't make them the current working directory.

So if anything is changed, it's for purity only. Then, for purity,
we should get it right and support any path that the operating system
supports.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9246>
_______________________________________

From report at bugs.python.org  Fri Jun 17 17:36:43 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jun 2011 15:36:43 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1308325003.08.0.415991722716.issue8716@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Bump, this failure is still happening on the ppc tiger buildbot periodically.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8716>
_______________________________________

From report at bugs.python.org  Fri Jun 17 17:40:06 2011
From: report at bugs.python.org (Bryan Jacobs)
Date: Fri, 17 Jun 2011 15:40:06 +0000
Subject: [issue12353] argparse cannot handle empty arguments
In-Reply-To: <1308325206.77.0.428682614263.issue12353@psf.upfronthosting.co.za>
Message-ID: <1308325206.77.0.428682614263.issue12353@psf.upfronthosting.co.za>


New submission from Bryan Jacobs <bjacobs at woti.com>:

Parsing arguments with argparse fails with an IndexError when one of the arguments is the empty string (''). This is caused by an access to the zero'th element of the argument value, without a preceding length check.

Fixed by the below patch:

Index: Lib/argparse.py
===================================================================
--- Lib/argparse.py
+++ Lib/argparse.py
@@ -1967,7 +1967,7 @@ class ArgumentParser(_AttributeHolder, _
         for arg_string in arg_strings:
 
             # for regular arguments, just add them back into the list
-            if arg_string[0] not in self.fromfile_prefix_chars:
+            if len(arg_string) == 0 or arg_string[0] not in self.fromfile_prefix_chars:
                 new_arg_strings.append(arg_string)
 
             # replace arguments referencing files with the file content

----------
components: Library (Lib)
messages: 138515
nosy: bjacobs
priority: normal
severity: normal
status: open
title: argparse cannot handle empty arguments
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12353>
_______________________________________

From report at bugs.python.org  Fri Jun 17 17:41:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jun 2011 15:41:07 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1308325267.04.0.860072965242.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> What about something like .decode('mbcs', errors='windows')?

Yes, we can use an error handler specific to the mbcs codec, but I would prefer to not introduce special error handlers.

For os.fsencode(), we can keep it unchanged, or add an optional "flags" argument to codecs.mbcs_decode().

> I still don't see the advantage of codecs.code_page_encode().

codecs.code_page_encode() and codecs.code_page_decode() are required for unit tests. If you don't want to add new public (C and Python) functions, we may add them to _testcapi.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Fri Jun 17 17:46:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 17 Jun 2011 15:46:50 +0000
Subject: [issue12313] make install misses test dirs for packaging and email
	modules
In-Reply-To: <1307722082.95.0.13819638115.issue12313@psf.upfronthosting.co.za>
Message-ID: <E1QXbFx-0000US-3m@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c9d27c63b45c by R David Murray in branch 'default':
#12313: update Makefile.pre.in to account for email tests moving to 'test' dir
http://hg.python.org/cpython/rev/c9d27c63b45c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12313>
_______________________________________

From report at bugs.python.org  Fri Jun 17 17:47:45 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jun 2011 15:47:45 +0000
Subject: [issue12313] make install misses test dirs for packaging and email
	modules
In-Reply-To: <1307722082.95.0.13819638115.issue12313@psf.upfronthosting.co.za>
Message-ID: <1308325665.2.0.737774686254.issue12313@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, regardless of whether or not I understand what's going on, clearly those directories in the makefile needed updating, so I did it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12313>
_______________________________________

From report at bugs.python.org  Fri Jun 17 17:56:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jun 2011 15:56:07 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1308326167.74.0.628098692169.issue4470@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Torsten, can you provide a clear, failing unittest for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Fri Jun 17 18:08:59 2011
From: report at bugs.python.org (Torsten Bronger)
Date: Fri, 17 Jun 2011 16:08:59 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1308326939.46.0.531305860916.issue4470@psf.upfronthosting.co.za>


Torsten Bronger <bronger at physik.rwth-aachen.de> added the comment:

No, I don't know how to do that.  All I can provide is a minimal version of my code that triggers the above mentioned traceback.  It is:

import smtplib

s = smtplib.SMTP_SSL("relay-auth.rwth-aachen.de")
s.login("***", "***")
s.sendmail("bronger at physik.rwth-aachen.de", "bronger.randys at googlemail.com"], "Hello")

I hope it helps to understand what I mean.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Fri Jun 17 18:11:20 2011
From: report at bugs.python.org (Torsten Bronger)
Date: Fri, 17 Jun 2011 16:11:20 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1308327080.95.0.545835063665.issue4470@psf.upfronthosting.co.za>


Torsten Bronger <bronger at physik.rwth-aachen.de> added the comment:

Sorry, it must be:

import smtplib

s = smtplib.SMTP_SSL("relay-auth.rwth-aachen.de")
s.login("***", "***")
s.sendmail("bronger at physik.rwth-aachen.de", ["bronger.randys at googlemail.com"], "Hello")

(A bracket was missing.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Fri Jun 17 18:32:19 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jun 2011 16:32:19 +0000
Subject: [issue12353] argparse cannot handle empty arguments
In-Reply-To: <1308325206.77.0.428682614263.issue12353@psf.upfronthosting.co.za>
Message-ID: <1308328339.18.0.510959597264.issue12353@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for the report and patch.  I'm setting this to test needed since the final patch will need a unit test.

The idiomatic way to do this kind of check is 'if not argstring or arg_string[0] not in self.fromfile_prefix_chars):'

----------
nosy: +bethard, r.david.murray
stage:  -> test needed
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12353>
_______________________________________

From report at bugs.python.org  Fri Jun 17 18:47:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jun 2011 16:47:53 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1308329273.7.0.545184516537.issue4470@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

According to your traceback you should be seeing the error in the first line (the creation of the SMTP_SSL object).  If I run that line at the python prompt of python2.7.1, I get your connection failure.  If I run it using 2.7 tip (or 3.3 tip), the connection succeeds.  I know there have been other fixes in this area, but I don't know which one makes the difference.

Torsten, can you test with 2.7.2 and/or 2.7 tip?

I'm not sure what is left to do in this issue.  Do you have an opinion, Lorenzo?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Fri Jun 17 19:00:38 2011
From: report at bugs.python.org (sbt)
Date: Fri, 17 Jun 2011 17:00:38 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>
Message-ID: <1308330038.46.0.96445798509.issue12328@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> You are right, we need a manual reset *or* we must ensure that every
> user of _PyOS_SigintEvent only does so from the main thread.

On second thoughts, even using an auto-reset event, resetting the event before waiting is unavoidable.  Otherwise you are liable to catch an event that was set a long time ago.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Fri Jun 17 19:10:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 17 Jun 2011 17:10:32 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <E1QXcYw-0007cf-7q@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset fea1920ae75f by R David Murray in branch '3.2':
#11767: use context manager to close file in __getitem__ to prevent FD leak
http://hg.python.org/cpython/rev/fea1920ae75f

New changeset 1d7a91358517 by R David Murray in branch 'default':
merge #11767: use context manager to close file in __getitem__ to prevent FD leak
http://hg.python.org/cpython/rev/1d7a91358517

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11767>
_______________________________________

From report at bugs.python.org  Fri Jun 17 19:21:06 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jun 2011 17:21:06 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1308331266.26.0.2582538059.issue11767@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The patch doesn't work on 2.7.  The failures are related to #11700, although that would seem to indicate that something *is* trying to close the file.  I have no idea what.

----------
dependencies: +mailbox.py proxy updates

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11767>
_______________________________________

From report at bugs.python.org  Fri Jun 17 19:25:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Jun 2011 17:25:03 +0000
Subject: [issue12347] add an "extras" in packaging.pypi.simple.Crawler
In-Reply-To: <1308234134.22.0.149772690275.issue12347@psf.upfronthosting.co.za>
Message-ID: <1308331503.41.0.19315691079.issue12347@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> tarek
components: +Distutils2
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12347>
_______________________________________

From report at bugs.python.org  Fri Jun 17 19:25:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Jun 2011 17:25:26 +0000
Subject: [issue12348] case sensitivity  in packaging.pypi.simple.Crawler
In-Reply-To: <1308237667.78.0.20758863265.issue12348@psf.upfronthosting.co.za>
Message-ID: <1308331526.0.0.520472493067.issue12348@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> tarek
components: +Distutils2
nosy: +eric.araujo
title: case sensitivness  in packaging.pypi.simple.Crawler -> case sensitivity  in packaging.pypi.simple.Crawler
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12348>
_______________________________________

From report at bugs.python.org  Fri Jun 17 19:27:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Jun 2011 17:27:36 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1308331656.78.0.279395943109.issue12326@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Martin?s sys.platform = 'linux' sounds good to me too.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Jun 17 19:34:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Jun 2011 17:34:21 +0000
Subject: [issue5572] distutils ignores the LIBS configure env var
In-Reply-To: <1238095013.07.0.627782689433.issue5572@psf.upfronthosting.co.za>
Message-ID: <1308332061.98.0.636013022742.issue5572@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> This wasn't so much a feature request as a request for review.
>From a tracker process viewpoint, any report is a bug, a feature request or a doc bug.  A bug can be defined as a discrepancy between the doc and the code.  Given that I found no mention of LIBS support in distutils, I tentatively took the conservative way and judged this a new feature.  However..

> We found this change necessary when working on Unladen Swallow.
This may change the situation.  Why was it necessary?  Would other projects need it?  Is it a standard in other build tools that?s an obvious oversight in distutils?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5572>
_______________________________________

From report at bugs.python.org  Fri Jun 17 19:36:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Jun 2011 17:36:19 +0000
Subject: [issue12333] test_packaging failures under Solaris
In-Reply-To: <1308061607.43.0.119074494077.issue12333@psf.upfronthosting.co.za>
Message-ID: <1308332179.31.0.443710898737.issue12333@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for tackling this while I was offline.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12333>
_______________________________________

From report at bugs.python.org  Fri Jun 17 19:41:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 17 Jun 2011 17:41:35 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <E1QXd30-0001px-Lv@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 27a70dfc38cc by ?ric Araujo in branch 'default':
Packaging tests: don?t let an internal cache grow indefinitely.
http://hg.python.org/cpython/rev/27a70dfc38cc

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Fri Jun 17 19:41:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Jun 2011 17:41:58 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1308332518.46.0.720759697591.issue12167@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I could not find any test in distutils/tests that imports extension modules.

test_build_ext builds and imports xx.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Fri Jun 17 19:42:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Jun 2011 17:42:20 +0000
Subject: [issue12133] ResourceWarning in urllib.request
In-Reply-To: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>
Message-ID: <1308332540.26.0.419751215792.issue12133@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yay!

----------
nosy: +alexis, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12133>
_______________________________________

From report at bugs.python.org  Fri Jun 17 19:43:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Jun 2011 17:43:46 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1308332626.44.0.774208656252.issue12167@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We?re down to 100 refleaks.  Thanks to the negative refleaks of test_pydoc, we now have a few refleaks to spare!  Seriously, what does a negative refleak mean?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Fri Jun 17 19:44:59 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Fri, 17 Jun 2011 17:44: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: <1308332699.09.0.272390941201.issue11767@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Should I try to do something about this right now or should I wait until #1170 is finished&closed and only then try to fix this issue too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11767>
_______________________________________

From report at bugs.python.org  Fri Jun 17 19:47:06 2011
From: report at bugs.python.org (Collin Winter)
Date: Fri, 17 Jun 2011 17:47:06 +0000
Subject: [issue5572] distutils ignores the LIBS configure env var
In-Reply-To: <1238095013.07.0.627782689433.issue5572@psf.upfronthosting.co.za>
Message-ID: <1308332826.36.0.354179587147.issue5572@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

I have provided justification in the original patch submission. Without this patch, we were unable to cleanly apply gcc's feedback-directed optimization system to Python. FDO yields significant performance improvements.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5572>
_______________________________________

From report at bugs.python.org  Fri Jun 17 19:50:25 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Fri, 17 Jun 2011 17:50:25 +0000
Subject: [issue6584] gzip module has no custom exception
In-Reply-To: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>
Message-ID: <1308333025.43.0.15299842882.issue6584@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Bump! Antoine, do you think the patch is acceptable and can be committed now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6584>
_______________________________________

From report at bugs.python.org  Fri Jun 17 20:00:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jun 2011 18:00:25 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1308333625.95.0.966735990944.issue11767@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, if you want to you could investigate further, and try the patch from #11700 and see what is left to do here after it has been applied.  I'll try to get 11700 in soon, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11767>
_______________________________________

From report at bugs.python.org  Fri Jun 17 20:16:14 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Fri, 17 Jun 2011 18:16:14 +0000
Subject: [issue12354] packaging.pypi.simple docs use both client and crawler
	variable, which might be confusing
In-Reply-To: <1308334574.8.0.60329566716.issue12354@psf.upfronthosting.co.za>
Message-ID: <1308334574.8.0.60329566716.issue12354@psf.upfronthosting.co.za>


New submission from Filip Gruszczy?ski <gruszczy at gmail.com>:

In documentation for packaging.pypi.simple in first code snippet crawler variable is created on which further operations will be performed. However in all next snippets there is client variable, which is a little confusing on first sight. This could be consistent throughout the whole page.

----------
assignee: docs at python
components: Distutils2, Documentation
messages: 138538
nosy: alexis, docs at python, eric.araujo, gruszczy
priority: normal
severity: normal
status: open
title: packaging.pypi.simple docs use both client and crawler variable, which might be confusing
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12354>
_______________________________________

From report at bugs.python.org  Fri Jun 17 20:20:13 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Fri, 17 Jun 2011 18:20:13 +0000
Subject: [issue12354] packaging.pypi.simple docs use both client and crawler
	variable, which might be confusing
In-Reply-To: <1308334574.8.0.60329566716.issue12354@psf.upfronthosting.co.za>
Message-ID: <1308334813.12.0.977921702672.issue12354@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

And a small, quick patch to docs.

----------
keywords: +patch
Added file: http://bugs.python.org/file22396/12354.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12354>
_______________________________________

From report at bugs.python.org  Fri Jun 17 20:22:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Jun 2011 18:22:35 +0000
Subject: [issue12354] packaging.pypi.simple docs use both client and crawler
	variable, which might be confusing
In-Reply-To: <1308334574.8.0.60329566716.issue12354@psf.upfronthosting.co.za>
Message-ID: <1308334955.07.0.363212318892.issue12354@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  I?m editing the doc to fix all instances of client and also improve phrasing in the whole file.

----------
assignee: docs at python -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12354>
_______________________________________

From report at bugs.python.org  Fri Jun 17 20:31:11 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jun 2011 18:31:11 +0000
Subject: [issue12342] characters with ord above 65535 fail to display in IDLE
In-Reply-To: <1308171600.34.0.388895530939.issue12342@psf.upfronthosting.co.za>
Message-ID: <1308335471.02.0.0858950499616.issue12342@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>ValueError: unsupported character (U+10000): Tcl doesn't support characters outside U+0000-U+FFFF range

Slightly shorter and without the double :s.

ValueError: character U+10000 is above the range (U+0000-U+FFFF) allowed by Tcl/Tk.

I agree with a change like this. People are going to increasingly use non-BMP chars and need to find out that the problem is not our fault.

----------
components: +Tkinter -IDLE, IO
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12342>
_______________________________________

From report at bugs.python.org  Fri Jun 17 20:42:10 2011
From: report at bugs.python.org (Lars Wirzenius)
Date: Fri, 17 Jun 2011 18:42:10 +0000
Subject: [issue12350] Improve stat_result.st_blocks and st_blksize
	documentation
In-Reply-To: <1308256127.22.0.581997138097.issue12350@psf.upfronthosting.co.za>
Message-ID: <1308336130.2.0.102232281084.issue12350@psf.upfronthosting.co.za>


Lars Wirzenius <liw at liw.fi> added the comment:

Right. So I guess at least the following should be changed (I'll make an actual patch once there's consensus):

* st_blocks should say that the size of block is often 512 bytes, but that's not guaranteed, and there's no way to know for sure

* st_blksize should say it is size of efficient I/O, and is unrelated to st_blocks

Should there be something more? Ideally, there should be a way to find out the size of blocks for st_blocks, but I don't know how to figure that out (though probably code from GNU's du could be borrowed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12350>
_______________________________________

From report at bugs.python.org  Fri Jun 17 20:46:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jun 2011 18:46:13 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1308336373.27.0.689184223065.issue12167@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It means that objects were garbage collected.  The refleak test runs the test multiple times, and ignores the first N runs to allow the object count to "settle".  But sometimes it either doesn't settle, or later runs end up with objects getting garbage collected that were created in earlier runs.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Fri Jun 17 20:46:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jun 2011 18:46:19 +0000
Subject: [issue6584] gzip module has no custom exception
In-Reply-To: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>
Message-ID: <1308336379.51.0.42854959766.issue6584@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Your changes appear to address all three of Antoine's 'nits'.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6584>
_______________________________________

From report at bugs.python.org  Fri Jun 17 20:49:33 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jun 2011 18:49:33 +0000
Subject: [issue12350] Improve stat_result.st_blocks and st_blksize
	documentation
In-Reply-To: <1308256127.22.0.581997138097.issue12350@psf.upfronthosting.co.za>
Message-ID: <1308336573.05.0.0835072166744.issue12350@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think that wording is as good as we can do for now.  Providing a way to determine the size of st_blocks blocks should be a separate issue (a feature request).  That enhancement can include an update to these docs, but since it is an enhancement it will only go into the development version.  But your wording fix should go into all maintained versions.

I think your suggested rewording is reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12350>
_______________________________________

From report at bugs.python.org  Fri Jun 17 20:55:00 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 17 Jun 2011 18:55:00 +0000
Subject: [issue9246] os.getcwd() hardcodes max path len
In-Reply-To: <1279023059.26.0.245683093399.issue9246@psf.upfronthosting.co.za>
Message-ID: <1308336900.19.0.422780385043.issue9246@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/issue9246>
_______________________________________

From report at bugs.python.org  Fri Jun 17 20:55:59 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 17 Jun 2011 18:55:59 +0000
Subject: [issue12346] Python 2.7.2 source code build (release) depends on
	mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1308336959.4.0.305665239599.issue12346@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/issue12346>
_______________________________________

From report at bugs.python.org  Fri Jun 17 21:07:50 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Fri, 17 Jun 2011 19:07:50 +0000
Subject: [issue12348] case sensitivity  in packaging.pypi.simple.Crawler
In-Reply-To: <1308237667.78.0.20758863265.issue12348@psf.upfronthosting.co.za>
Message-ID: <1308337670.57.0.398529302108.issue12348@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

When I started looking at this I noticed following behaviour:

>>> from packaging.pypi.simple import Crawler
>>> client = Crawler()
>>> client.get_releases('webob')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/gruszczy/Projects/python/Lib/packaging/pypi/simple.py", line 192, in get_releases
    self._process_index_page(predicate.name)
packaging.pypi.errors.ProjectNotFound
>>> client.search_projects('webob')
[<Project "WebOb">, <Project "webob_view">, <Project "yafowil.webob">]
>>> client.get_releases('webob')
<Project "WebOb">

Shouldn't this be made consistent?

----------
nosy: +gruszczy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12348>
_______________________________________

From report at bugs.python.org  Fri Jun 17 22:13:32 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Fri, 17 Jun 2011 20:13:32 +0000
Subject: [issue12355] Crawler doesn't follow redirection
In-Reply-To: <1308341612.08.0.583643190206.issue12355@psf.upfronthosting.co.za>
Message-ID: <1308341612.08.0.583643190206.issue12355@psf.upfronthosting.co.za>


New submission from Filip Gruszczy?ski <gruszczy at gmail.com>:

When looking at issue #12348 I have noticed following behaviour:

from packaging.pypi.simple import Crawler
c = Crawler()
c.get_releases('webob')

Traceback (most recent call last):
  File "test_crawl.py", line 3, in <module>
    c.get_releases('webob')
  File "/home/gruszczy/Projects/python/Lib/packaging/pypi/simple.py", line 192, in get_releases
    raise ProjectNotFound
packaging.pypi.errors.ProjectNotFound

This is because when request for /simple/webob/ is made 301 is returned to /simple/WebOb/ and HttpError raised, which is silenced and returned:

        except urllib.error.HTTPError as v:
            return v

Wouldn't it be good to do something about? How about crawler following redirects?

----------
assignee: tarek
components: Distutils2
messages: 138547
nosy: alexis, eric.araujo, gruszczy, tarek
priority: normal
severity: normal
status: open
title: Crawler doesn't follow redirection
type: crash
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12355>
_______________________________________

From report at bugs.python.org  Fri Jun 17 22:33:38 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 17 Jun 2011 20:33:38 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=Hijk1FirGnf=fxooWuGKNSKT=vNtqkyj2a_uY-gC_XA@mail.gmail.com>


Daniel Stutzbach <stutzbach at google.com> added the comment:

On Wed, Jun 15, 2011 at 8:10 PM, Nick Coghlan <report at bugs.python.org>wrote:

> I'd like to add a new constant to the math module:
>
>  tau = 2*math.pi
>
> Rather than repeating all the reasons for why tau makes more sense than pi
> as the fundamental circle constant, I'll just refer interested readers to
> http://tauday.com/

(The following is best if read aloud using your best pirate impression)

I'd rather name the new constant "matey".  Then we have:

The circumference of a circle is: r matey
The area of a circle is: one-quarter r r matey
etc.

----------
nosy: +stutzbach
Added file: http://bugs.python.org/file22397/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12345>
_______________________________________
-------------- next part --------------
<div class="gmail_quote">On Wed, Jun 15, 2011 at 8:10 PM, Nick Coghlan <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;">
I&#39;d like to add a new constant to the math module:<br>
<br>
 ??tau = 2*math.pi<br>
<br>
Rather than repeating all the reasons for why tau makes more sense than pi as the fundamental circle constant, I&#39;ll just refer interested readers to <a href="http://tauday.com/" target="_blank">http://tauday.com/</a></blockquote>
<div><br></div><div>(The following is best if read aloud using your best pirate impression)</div><div><br></div><div>I&#39;d rather name the new constant &quot;matey&quot;. ??Then we have:</div><div><br></div><div>The circumference??of a circle is: r matey</div>
<div>The area of a circle is: one-quarter r r matey</div><div>etc.</div></div><br>-- <br>Daniel Stutzbach<br>

From report at bugs.python.org  Fri Jun 17 22:36:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Jun 2011 20:36:24 +0000
Subject: [issue12355] Crawler doesn't follow redirection
In-Reply-To: <1308341612.08.0.583643190206.issue12355@psf.upfronthosting.co.za>
Message-ID: <1308342984.78.0.184842823585.issue12355@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sure, let?s follow redirections (and log them).

----------
stage:  -> needs patch
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12355>
_______________________________________

From report at bugs.python.org  Fri Jun 17 22:37:52 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Fri, 17 Jun 2011 20:37:52 +0000
Subject: [issue12355] Crawler doesn't follow redirection
In-Reply-To: <1308341612.08.0.583643190206.issue12355@psf.upfronthosting.co.za>
Message-ID: <1308343072.63.0.453269593604.issue12355@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

OK, I'll try to come up with some patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12355>
_______________________________________

From report at bugs.python.org  Fri Jun 17 23:04:54 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 17 Jun 2011 21:04:54 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1308344694.91.0.145883471612.issue12345@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Not to mention d(area of circle of radius r) = r dr matey.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Fri Jun 17 23:09:37 2011
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Fri, 17 Jun 2011 21:09:37 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1308329273.7.0.545184516537.issue4470@psf.upfronthosting.co.za>
Message-ID: <alpine.DEB.2.02.1106172239390.9902@ronzinante.ccd.uniroma2.it>


Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it> added the comment:

On Fri, 17 Jun 2011, R. David Murray wrote:

RDM> 
RDM> R. David Murray <rdmurray at bitdance.com> added the comment:
RDM> 
RDM> According to your traceback you should be seeing the error in the 
RDM> first line (the creation of the SMTP_SSL object).  If I run that line 
RDM> at the python prompt of python2.7.1, I get your connection failure.  
RDM> If I run it using 2.7 tip (or 3.3 tip), the connection succeeds.  I 
RDM> know there have been other fixes in this area, but I don't know which 
RDM> one makes the difference.
RDM> 
RDM> Torsten, can you test with 2.7.2 and/or 2.7 tip?
RDM> 
RDM> I'm not sure what is left to do in this issue.  Do you have an 
RDM> opinion, Lorenzo?
RDM> 

Torsten, would you mind letting us know both the python and the .deb 
version by running 

$ python2.7 --version

and

$ dpkg -l python2.7

At least in debian's python2.7_2.7.1-8, default_port is still an instance 
attribute instead of a class attribute. 

If the ubuntu situation is the same, the missing patch is 
smtplib_01_default_port.diff , and you could work-around the problem by 
explicitly calling s = smtplib.SMTP_SSL("relay-auth.rwth-aachen.de", 465).

The patch got in with:

changeset:   69931:bcf04ced5ef1
branch:      2.7
parent:      69915:7c3a20b5943a
user:        Antoine Pitrou <solipsis at pitrou.net>
date:        Sat May 07 19:59:33 2011 +0200
summary:     Issue #11927: SMTP_SSL now uses port 465 by default as 
documented.  Patch by Kasun Herath.

The last hunk, which fixes LMTP is still missing.

@@ -776,8 +777,9 @@
     authentication, but your mileage might vary."""

     ehlo_msg = "lhlo"
+    default_port = LMTP_PORT

-    def __init__(self, host = '', port = LMTP_PORT, local_hostname = 
None):
+    def __init__(self, host = '', port = 0, local_hostname = None):
         """Initialize a new instance."""
         SMTP.__init__(self, host, port, local_hostname)

Have a nice week-end, yours

	lorenzo

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Fri Jun 17 23:14:55 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Jun 2011 21:14:55 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1308345295.75.0.88102589505.issue12345@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> http://tauday.com/

And I thought putting "dx" directly next to the integral sign was audacious...

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Fri Jun 17 23:25:06 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jun 2011 21:25:06 +0000
Subject: [issue12298] Sphinx glitch in library/functions
In-Reply-To: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za>
Message-ID: <1308345906.05.0.881966267005.issue12298@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree that all table entries should link to the entry in the same file.

dict() and set() also jump to CH. 4, in addition to memoryview and frozenset. Others all work properly.

The entries for classes should generally have a link to their section in '4. Built-in Types'. All do other than these:

range() definitely needs a forward reference to 4.6 sequence types 

bool() lacks forward references; it could have one to 4.2 Bool ops and 4.11.9 Bool values

object() -- no where to go.

slice() only has a reference to the glossary; it has no entry in Ch.4. "Slice objects have read-only data attributes start, stop and step which merely return the argument values (or their default). They have no other explicit functionality" is slightly wrong since there is the .indices method.

type(n,b,d) has no forward references as there is no where to go exactly

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12298>
_______________________________________

From report at bugs.python.org  Fri Jun 17 23:32:10 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Fri, 17 Jun 2011 21:32:10 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1308346330.91.0.517182665394.issue4470@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

Most of the problems in this issue were solved already so it could almost be closed:
* patch 1 was addressed in #11927
* patch 2 was addressed in #4066
* patches 3 and 4 were addressed in #11893

Torsten's problem was addressed by bcf04ced5ef1.

> I'm not sure what is left to do in this issue.

The only patch remaining is patch 5. I attached an updated version against tip of default branch. My patch mimics shutdown in imaplib.py in that it silences ENOTCONN. However I don't have a test that fails without the shutdown and I don't know if checking ENOTCONN is really needed. I tried to get shutdown to produce ENOTCONN by using Postfix as a server with smtpd_timeout=5s, connecting to it and waiting idle for more than 5 seconds before doing close(). In the Postfix logs I see that Postfix disconnects after 5 seconds of inactivity but doing shutdown afterwards doesn't trigger any exception so the ENOTCONN part remains unexercised.

My patch also adds shutdown method and SHUT_RDWR constant to mock_socket.py since otherwise test_smtplib fails.

(Added Antoine to nosy because he reviewed the patches for #11927 and #11893)

----------
nosy: +catalin.iacob, pitrou
Added file: http://bugs.python.org/file22398/smtplib_05_shutdown_socket_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Sat Jun 18 00:54:05 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jun 2011 22:54:05 +0000
Subject: [issue12315] Improve http.client.HTTPResponse.read documentation
In-Reply-To: <1307733776.17.0.904388798994.issue12315@psf.upfronthosting.co.za>
Message-ID: <1308351245.68.0.24192047433.issue12315@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The patch does 3 things:

1. clarify that 'amt' in 'the next amt bytes' means 'amount'.

I do not think this is necessary; 'the next blah bytes' is clear. Actually, 'amt' really means 'number', not 'amount', which would imply that 'amt' is a float, not an int. 'amt' was a poor choice of parameter name and should have been 'n' or 'nbytes' I presume it has to be an int, not a float. Since it is passed on to the socket file wrapper, I suspect that io.rawiobase."read(n=-1) 
Read up to n bytes from the object and return them. As a convenience, if n is unspecified or -1, readall() is called. Otherwise, only one system call is ever made. Fewer than n bytes may be returned if the operating system call returns fewer than n bytes.

If 0 bytes are returned, and n was not 0, this indicates end of file. If the object is in non-blocking mode and no bytes are available, None is returned."
applies, but I am not really sure.

2. Add an example after the entry for .read().
This seems out of place since there is already a section for examples. All three of the existing examples use response.read. One of them could be enlarged slightly to read in chunks if an example is needed.

3. Document .closed
If it were mentioned that HTTPResponse is a subclass of RawIOBase, and perhaps it should be, the existence of .closed might be inferred. But since not everything is implemented, and since .closed is useful to iterate (as should be the example), I agree this should be added.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12315>
_______________________________________

From report at bugs.python.org  Sat Jun 18 00:57:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Jun 2011 22:57:56 +0000
Subject: [issue9246] os.getcwd() hardcodes max path len
In-Reply-To: <1279023059.26.0.245683093399.issue9246@psf.upfronthosting.co.za>
Message-ID: <1308351476.11.0.144096932626.issue9246@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> From a practicality point of view, we need to make no change at all:
> nobody sane ever has a current working directory path of more than
> 1000 characters. Even if people have very long path names, they
> don't make them the current working directory.

I don't see why that wouldn't be the case. They probably don't change to these directories *by hand*, but they can have scripts that cd into such a directory before doing stuff inside it. And these scripts can be written in Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9246>
_______________________________________

From report at bugs.python.org  Sat Jun 18 00:58:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jun 2011 22:58:28 +0000
Subject: [issue12317] inspect.getabsfile() is not documented
In-Reply-To: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za>
Message-ID: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

>>> help(inspect.getabsfile) could be copied

getabsfile(object, _filename=None)
    Return an absolute path to the source or compiled file for an object.
    
    The idea is for each object to have a unique origin, so this routine
    normalizes the result as much as possible.

----------
components: +Documentation
nosy: +terry.reedy
stage:  -> needs patch
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12317>
_______________________________________

From report at bugs.python.org  Sat Jun 18 01:04:20 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jun 2011 23:04:20 +0000
Subject: [issue12321] documentation of ElementTree.find
In-Reply-To: <1307958561.6.0.547513151308.issue12321@psf.upfronthosting.co.za>
Message-ID: <1308351860.94.0.778184033903.issue12321@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Are you requesting that the doc be changed or the code?
>From the title, I would infer the doc (which is much easier ;-).
If so, can you suggest an actual revised text?

----------
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12321>
_______________________________________

From report at bugs.python.org  Sat Jun 18 01:18:31 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jun 2011 23:18:31 +0000
Subject: [issue12337] Need real TextIOWrapper for stdin/stdout
In-Reply-To: <1308113993.07.0.688068575261.issue12337@psf.upfronthosting.co.za>
Message-ID: <1308352711.05.0.663746742217.issue12337@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

WinXP, 3.2.0
>>> type(sys.stdin)
<class 'idlelib.rpc.RPCProxy'>
>>> sys.stdin.readline()
a
'a\n'

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12337>
_______________________________________

From report at bugs.python.org  Sat Jun 18 01:30:56 2011
From: report at bugs.python.org (Torsten Bronger)
Date: Fri, 17 Jun 2011 23:30:56 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1308353456.53.0.934264253696.issue4470@psf.upfronthosting.co.za>


Torsten Bronger <bronger at physik.rwth-aachen.de> added the comment:

My Python version is "Python 2.7.1+" and the package is called "python2.7 2.7.1-5ubuntu2" (Ubuntu Natty).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Sat Jun 18 01:46:00 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jun 2011 23:46:00 +0000
Subject: [issue12337] Need real TextIOWrapper for stdin/stdout
In-Reply-To: <1308113993.07.0.688068575261.issue12337@psf.upfronthosting.co.za>
Message-ID: <1308354360.54.0.0128869632515.issue12337@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not sure what the point of your example is, Terry.  Is it not fixed in 3.2.1?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12337>
_______________________________________

From report at bugs.python.org  Sat Jun 18 02:45:32 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 18 Jun 2011 00:45:32 +0000
Subject: [issue12356] more argument error improving
In-Reply-To: <1308357931.79.0.860556100237.issue12356@psf.upfronthosting.co.za>
Message-ID: <1308357931.79.0.860556100237.issue12356@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

After completing #12265, it was pointed out to me that the error message is still not perfect:

>>> def f(a, b, c=3, d=4, e=6, f=3, g=32): pass
... 
>>> f(1, f=4, d=90)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes from 2 to 7 positional arguments but 3 were given

Here is a new patch.

Some samples:

>>> def f(a): pass
... 
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() missing 1 required positional argument: 'a'
>>> def f(a, b): pass
... 
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() missing 2 required positional arguments: 'a' and 'b'

>>> def f(a, b, c): pass
... 
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() missing 3 required positional arguments: 'a', 'b', and 'c
>>> def f(a, b, c, d): pass
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() missing 4 required positional arguments: 'a', 'b', 'c', and 'd'

Same with kwonly:

>>> def f(*, w): pass
... 
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() missing 1 required keyword-only argument: 'w'
>>> def f(*, a, b, c, d, e): pass
... 
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() missing 5 required keyword-only arguments: 'a', 'b', 'c', 'd', and 'e'

For too many positional arguments, the old (new) error is retained:

>>> def f(a): pass
... 
>>> f(1, 2, 3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes 1 positional argument but 3 were given
>>> f(3, 4, 5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes from 1 to 2 positional arguments but 3 were given

----------
components: Interpreter Core
files: argerror.patch
keywords: patch
messages: 138563
nosy: benjamin.peterson
priority: normal
severity: normal
stage: patch review
status: open
title: more argument error improving
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22399/argerror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12356>
_______________________________________

From report at bugs.python.org  Sat Jun 18 03:20:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Jun 2011 01:20:41 +0000
Subject: [issue12346] Python 2.7.2 source code build (release) depends on
	mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1308360041.09.0.701481194755.issue12346@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The regexes are now in the right order.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12346>
_______________________________________

From report at bugs.python.org  Sat Jun 18 04:26:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 18 Jun 2011 02:26:09 +0000
Subject: [issue11700] mailbox.py proxy updates
In-Reply-To: <1301315190.34.0.276151285444.issue11700@psf.upfronthosting.co.za>
Message-ID: <E1QXlEd-0000r7-G4@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b89d193cbca5 by R David Murray in branch '2.7':
#11700: proxy object close methods can now be called multiple times
http://hg.python.org/cpython/rev/b89d193cbca5

New changeset 8319db2dd342 by R David Murray in branch '3.2':
#11700: proxy object close methods can now be called multiple times
http://hg.python.org/cpython/rev/8319db2dd342

New changeset 0705b9037b20 by R David Murray in branch 'default':
merge #11700: proxy object close methods can now be called multiple times
http://hg.python.org/cpython/rev/0705b9037b20

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11700>
_______________________________________

From report at bugs.python.org  Sat Jun 18 04:28:18 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jun 2011 02:28:18 +0000
Subject: [issue11700] mailbox.py proxy close method cannot be called multiple
	times
In-Reply-To: <1301315190.34.0.276151285444.issue11700@psf.upfronthosting.co.za>
Message-ID: <1308364098.72.0.806164303692.issue11700@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
title: mailbox.py proxy updates -> mailbox.py proxy close method cannot be called multiple times
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11700>
_______________________________________

From report at bugs.python.org  Sat Jun 18 04:39:55 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jun 2011 02:39:55 +0000
Subject: [issue11767] Maildir iterator leaks file descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1308364795.26.0.176444764208.issue11767@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, it turns out I was totally wrong about the 11700 dependency.  I misread the errors that were produced by the test suite.  Even after fixing 11700 they are still there: the tests are reading from the closed files.  So something changed in the logic between 2.7 and 3.x.  It is possible that this is related to the addition of context manager support, and is almost certainly related to the general cleanup of unclosed files that was done after Antoine's ResourceWarning patch.

Filip, do you want to investigate this?  We always have the option of ignoring the problem in 2.7, but since you reported it against 2.7 I'm guessing you'd like to see it fixed there.

I'm attaching a version of the patch that applies cleanly to 2.7 tip.

----------
dependencies:  -mailbox.py proxy close method cannot be called multiple times
Added file: http://bugs.python.org/file22400/mailbox_fd_loss.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11767>
_______________________________________

From report at bugs.python.org  Sat Jun 18 06:44:16 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Jun 2011 04:44:16 +0000
Subject: [issue12337] Need real TextIOWrapper for stdin/stdout
In-Reply-To: <1308113993.07.0.688068575261.issue12337@psf.upfronthosting.co.za>
Message-ID: <1308372256.86.0.12504490092.issue12337@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

That, like Antoine, I also could not reproduce, even in 3.2.0, when running under IDLE. However, with regular command line Python:
Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)]
>>> import sys
>>> sys.stdin.readline()
a
'a\r\n'
so there really was a bug. If fixed in 3.2.1, this issue could be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12337>
_______________________________________

From report at bugs.python.org  Sat Jun 18 09:24:32 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 18 Jun 2011 07:24:32 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1308381872.23.0.776668617981.issue11197@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Ori, which platform did you try to reproduce this issue. I tried in all active codelines (cpython to all through 2.5) from hg and can't able to reproduce this bug on Linux. If someone can reproduce, can you provide exact instructions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11197>
_______________________________________

From report at bugs.python.org  Sat Jun 18 09:43:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 18 Jun 2011 07:43:18 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1308382998.19.0.418547702338.issue12167@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> test_build_ext builds and imports xx.

I changed test test to use a subprocess:

New changeset 144cea8db9a5 by Victor Stinner in branch 'default':
Issue #12333: run tests on the new module in a subprocess
http://hg.python.org/cpython/rev/144cea8db9a5

It should fix refleaks because it is not possible to unload a module written in C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Sat Jun 18 09:52:56 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Jun 2011 07:52:56 +0000
Subject: [issue12090] 3.2: build --without-threads fails
In-Reply-To: <1305568611.26.0.714455176679.issue12090@psf.upfronthosting.co.za>
Message-ID: <1308383576.0.0.968186545584.issue12090@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Is this done then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12090>
_______________________________________

From report at bugs.python.org  Sat Jun 18 10:15:07 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Jun 2011 08:15:07 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1308384907.96.0.270302253393.issue12291@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Any reviewers?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sat Jun 18 10:18:34 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Jun 2011 08:18:34 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1308385114.11.0.577879290261.issue9516@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Can the 3.2 part of this be resolved this weekend?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Sat Jun 18 10:26:23 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Jun 2011 08:26:23 +0000
Subject: [issue12290] __setstate__ is called for false values
In-Reply-To: <1307586060.34.0.652262251036.issue12290@psf.upfronthosting.co.za>
Message-ID: <1308385583.5.0.817211623904.issue12290@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, this looks correct then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12290>
_______________________________________

From report at bugs.python.org  Sat Jun 18 10:55:08 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 18 Jun 2011 08:55:08 +0000
Subject: [issue12090] 3.2: build --without-threads fails
In-Reply-To: <1305568611.26.0.714455176679.issue12090@psf.upfronthosting.co.za>
Message-ID: <1308387308.11.0.335907372646.issue12090@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Yes, this is fixed in 3.2. I just left the issue open as a reminder
for the release branch.

----------
resolution:  -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12090>
_______________________________________

From report at bugs.python.org  Sat Jun 18 10:55:59 2011
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Sat, 18 Jun 2011 08:55:59 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1308387359.19.0.582883068051.issue4470@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Added file: http://bugs.python.org/file22401/v2_01_fix_lmtp_init

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Sat Jun 18 10:56:57 2011
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Sat, 18 Jun 2011 08:56:57 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1308387417.05.0.771179470505.issue4470@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Added file: http://bugs.python.org/file22402/v2_02_mock_socket_shutdown

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Sat Jun 18 10:57:53 2011
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Sat, 18 Jun 2011 08:57:53 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1308387473.77.0.772280135871.issue4470@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Added file: http://bugs.python.org/file22403/v2_03_shutdown_socket_on_close

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Sat Jun 18 11:01:51 2011
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Sat, 18 Jun 2011 09:01:51 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1308387711.19.0.824174742186.issue4470@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Removed file: http://bugs.python.org/file22403/v2_03_shutdown_socket_on_close

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Sat Jun 18 11:17:15 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 18 Jun 2011 09:17:15 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1308388635.75.0.622788848314.issue9516@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I would like Ronald's take on it (also, I expect to be off-line for the weekend).  Note, as it stands now, 3.2.1 (without any further patches) would have the same less than ideal behavior as 2.7.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Sat Jun 18 11:25:35 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 18 Jun 2011 09:25:35 +0000
Subject: [issue12357] Python dist modifications for secure PyPI uploads
In-Reply-To: <1308389135.03.0.407441500692.issue12357@psf.upfronthosting.co.za>
Message-ID: <1308389135.03.0.407441500692.issue12357@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

This is the master ticket to support secure uploads of Python packages to PyPI servers using standard Python distribution.

Please, add issue12226 as a first child.

----------
assignee: tarek
components: Distutils, Distutils2, Installation
messages: 138576
nosy: alexis, eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: Python dist modifications for secure PyPI uploads
type: security
versions: Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12357>
_______________________________________

From report at bugs.python.org  Sat Jun 18 11:26:31 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 18 Jun 2011 09:26:31 +0000
Subject: [issue12226] use HTTPS by default for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1308389191.48.0.73130030963.issue12226@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

This simple patch slipped off 2.7.2. Why?

----------
title: use secured channel for uploading packages to pypi -> use HTTPS by default for uploading packages to pypi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Sat Jun 18 11:34:00 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 18 Jun 2011 09:34:00 +0000
Subject: [issue12358] validate server certificate when uploading packages to
	PyPI
In-Reply-To: <1308389640.44.0.96724424469.issue12358@psf.upfronthosting.co.za>
Message-ID: <1308389640.44.0.96724424469.issue12358@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Please add this as a child of master issue12357.

When default protocol to upload to PyPI is switched to HTTPS in issue12226, the next step is to validate the certificate. Certificate validation requires that we will either:

1. distribute root CACert certificate with Python (for some reason it is not included/trusted on Windows platform)
2. acquire certificate for PyPI servers from party trusted by default, so that system certificates can be used for validation

----------
messages: 138578
nosy: techtonik
priority: normal
severity: normal
status: open
title: validate server certificate when uploading packages to PyPI
type: security

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12358>
_______________________________________

From report at bugs.python.org  Sat Jun 18 11:34:19 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 18 Jun 2011 09:34:19 +0000
Subject: [issue12358] validate server certificate when uploading packages to
	PyPI
In-Reply-To: <1308389640.44.0.96724424469.issue12358@psf.upfronthosting.co.za>
Message-ID: <1308389659.61.0.743518928445.issue12358@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
assignee:  -> tarek
components: +Distutils, Distutils2
nosy: +alexis, eric.araujo, tarek
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12358>
_______________________________________

From report at bugs.python.org  Sat Jun 18 11:42:45 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 18 Jun 2011 09:42:45 +0000
Subject: [issue3067] setlocale fails with unicode strings on Py2 and with byte
	strings on Py3
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1308390165.72.0.334927084404.issue3067@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Sat Jun 18 11:56:46 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 18 Jun 2011 09:56:46 +0000
Subject: [issue12357] Python dist modifications for secure PyPI uploads
In-Reply-To: <1308389135.03.0.407441500692.issue12357@psf.upfronthosting.co.za>
Message-ID: <1308391006.99.0.203250345399.issue12357@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

..and issue12358 as a second.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12357>
_______________________________________

From report at bugs.python.org  Sat Jun 18 12:11:49 2011
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Sat, 18 Jun 2011 10:11:49 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1308391909.43.0.0284596352322.issue4470@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Removed file: http://bugs.python.org/file22402/v2_02_mock_socket_shutdown

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Sat Jun 18 12:26:48 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 18 Jun 2011 10:26:48 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1308392808.21.0.719754479892.issue9516@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I agree with Ned, the changes to the environment should only be done in subprocesses started by distutils.

The patch looks fine, but I haven't tested the patches yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Sat Jun 18 15:02:34 2011
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Sat, 18 Jun 2011 13:02:34 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1308402154.01.0.0378587890259.issue4470@psf.upfronthosting.co.za>


Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it> added the comment:

Just finished testing both 2.7 and default branches' socket close behaviour, and it seems 05 is not strictly needed.

I'd still prefer if smtplib_05_shutdown_socket_v2.patch since, this way the REMOTE socket close will be unconditionally correct, instead of being dependent on GC artifacts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Sat Jun 18 15:33:58 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 18 Jun 2011 13:33:58 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1308404038.75.0.334955355331.issue7652@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Removed file: http://bugs.python.org/file22304/9a10e3232445.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Sat Jun 18 15:36:17 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 18 Jun 2011 13:36:17 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1308404177.75.0.931079413205.issue7652@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file22404/49433f35a5f8.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Sat Jun 18 16:02:26 2011
From: report at bugs.python.org (Jakub Wilk)
Date: Sat, 18 Jun 2011 14:02:26 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1308405746.56.0.0921330499151.issue12326@psf.upfronthosting.co.za>


Jakub Wilk <jwilk at jwilk.net> added the comment:

Just to give some statistic, in Debian we have >80 binary packages that check if sys.platform is linux2. However, it appears to me that vast majority of them is broken anyway, because what they really mean to check is:
- is this a non-Windows sytem? or
- is this a UNIX-like system? or
- is this a system with GNU userland?

----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Jun 18 16:20:41 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 18 Jun 2011 14:20:41 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1308406841.16.0.120791599325.issue7652@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The latest patch is based on a relatively stable revision of 3.3. To my
knowledge, _decimal.c and decimal.py are now fully compatible in the
sense of PEP-399.



libmpdec
========

    o New test suite with comprehensive tests against decNumber.

    o Full support for 32-bit compilers (tested with CompCert).


PEP-399
=======

    o cdecimal.c is now called _decimal.c. Instead of importing cdecimal,
      _decimal is transparently imported as decimal (if the C version is
      available).

    o Unified unit tests with 100% code coverage for both decimal.py and
      _decimal.c. For _decimal.c, the tests include all failures of
      Python API functions (requires special patch for testing).

    o deccheck.py now also tests arbitrary input and makes sure that both
      modules raise the same exceptions.

    o Both modules produce the same pickle output for Decimal and Context.

_decimal.c
==========

    o Speed up int/Decimal conversion for integers that fit into a
      single word of a PyLongObject (performance gain is around 15%).

    o real(), imag(), conjugate(), __complex__() support.

    o Fraction and complex comparison support.

    o Decimal constructor now accepts lists as well as tuples.

    o DecimalTuple support.

    o General cleanup and refactoring. The functions for conversions 
      between Decimal and other numeric types are much cleaner now 
      and could be used for a PyDec_* API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Sat Jun 18 16:34:55 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 18 Jun 2011 14:34:55 +0000
Subject: [issue12359] tutorial: Module search path description is incorrect
In-Reply-To: <1308407695.09.0.303681719961.issue12359@psf.upfronthosting.co.za>
Message-ID: <1308407695.09.0.303681719961.issue12359@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/tutorial/modules.html#the-module-search-path

Module search path order description is misleading. When a module named spam is imported, the interpreter searches for a file named spam.py in the directory of the script with import instruction, not in the current directory.

----------
assignee: docs at python
components: Documentation
messages: 138584
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: tutorial: Module search path description is incorrect
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12359>
_______________________________________

From report at bugs.python.org  Sat Jun 18 16:42:54 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 18 Jun 2011 14:42:54 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1308408174.27.0.2946651415.issue12291@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Why can't you just call fileno() on the file object?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sat Jun 18 16:57:56 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jun 2011 14:57:56 +0000
Subject: [issue12359] tutorial: Module search path description is incorrect
In-Reply-To: <1308407695.09.0.303681719961.issue12359@psf.upfronthosting.co.za>
Message-ID: <1308409076.95.0.153824894715.issue12359@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The second paragraph goes on to cover your point, but I agree that it is not as clear as it should be.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12359>
_______________________________________

From report at bugs.python.org  Sat Jun 18 17:44:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jun 2011 15:44:59 +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: <1308411899.8.0.647659288582.issue11781@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I forgot that I had this issue open.  I committed the makefile part of the patch in issue 12313.  I currently have no way to test the windows part, but it seems a straightforward modification of the existing code, so I'm going to commit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11781>
_______________________________________

From report at bugs.python.org  Sat Jun 18 17:46:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 18 Jun 2011 15:46:25 +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: <E1QXxiz-000502-PY@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a6c5da661428 by R David Murray in branch 'default':
#11781: update windows build script to account for move of email tests
http://hg.python.org/cpython/rev/a6c5da661428

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11781>
_______________________________________

From report at bugs.python.org  Sat Jun 18 17:47:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jun 2011 15:47:07 +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: <1308412027.15.0.495442964997.issue11781@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11781>
_______________________________________

From report at bugs.python.org  Sat Jun 18 18:34:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 18 Jun 2011 16:34:18 +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: <E1QXyTQ-0007t2-IL@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d62e5682a8ac by R David Murray in branch '3.2':
#11584: make decode_header handle Header objects correctly
http://hg.python.org/cpython/rev/d62e5682a8ac

New changeset ce033d252a6d by R David Murray in branch 'default':
merge #11584: make decode_header handle Header objects correctly
http://hg.python.org/cpython/rev/ce033d252a6d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11584>
_______________________________________

From report at bugs.python.org  Sat Jun 18 19:03:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 18 Jun 2011 17:03:00 +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: <E1QXyvD-0001Z1-K3@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3875ccea6367 by R David Murray in branch '3.2':
#11584: make Header and make_header handle binary unknown-8bit input
http://hg.python.org/cpython/rev/3875ccea6367

New changeset 9569d8c4c781 by R David Murray in branch 'default':
merge #11584: make Header and make_header handle binary unknown-8bit input
http://hg.python.org/cpython/rev/9569d8c4c781

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11584>
_______________________________________

From report at bugs.python.org  Sat Jun 18 19:04:27 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jun 2011 17:04:27 +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: <1308416667.0.0.326951028943.issue11584@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, the invariant make_header(decode_header(x)) == x should once again work for anything returned by __getitem__.

----------
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11584>
_______________________________________

From report at bugs.python.org  Sat Jun 18 19:51:10 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jun 2011 17:51:10 +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: <1308419470.25.0.63447553323.issue11584@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Heh, I misstated that invariant, it's only true when x is a Header.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11584>
_______________________________________

From report at bugs.python.org  Sat Jun 18 19:54:20 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jun 2011 17:54:20 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1308419660.12.0.185625211911.issue11873@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status:  -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11873>
_______________________________________

From report at bugs.python.org  Sat Jun 18 19:57:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jun 2011 17:57:01 +0000
Subject: [issue12346] Python source code build (release) depends on mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1308419821.0.0.243725674985.issue12346@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: Python 2.7.2 source code build (release) depends on mercurial -> Python source code build (release) depends on mercurial

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12346>
_______________________________________

From report at bugs.python.org  Sat Jun 18 20:12:43 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jun 2011 18:12:43 +0000
Subject: [issue3216] Scarce msilib documentation
In-Reply-To: <1214577470.61.0.590067451474.issue3216@psf.upfronthosting.co.za>
Message-ID: <1308420763.16.0.659962768201.issue3216@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords:  -easy, patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3216>
_______________________________________

From report at bugs.python.org  Sat Jun 18 20:52:15 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 18 Jun 2011 18:52:15 +0000
Subject: [issue9246] os.getcwd() hardcodes max path len
In-Reply-To: <1279023059.26.0.245683093399.issue9246@psf.upfronthosting.co.za>
Message-ID: <1308423135.17.0.760403379832.issue9246@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9246>
_______________________________________

From report at bugs.python.org  Sat Jun 18 21:58:00 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jun 2011 19:58:00 +0000
Subject: [issue12147] smtplib.send_message does not implement corectly rfc 2822
In-Reply-To: <1306050881.77.0.236550216984.issue12147@psf.upfronthosting.co.za>
Message-ID: <1308427080.04.0.318923681623.issue12147@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think we can treat this as a bug.  However...

What if there is more than one set of Resent- headers?  I think that it is not possible to guarantee we only look at the most recent set, since the RFC provides no way to identify a "set".  Heuristically we could probably guess right 99% of the time, but we'd still be guessing.  Further, the RFC actually prohibits using the Resent- headers for "automated processing", though, granted, it is talking about the receiving end, not the sending end.

My inclination at this point is to fix the Sender bug, and to refuse to guess when there are any Resent- headers (throw a ValueError).  I've queried the email-sig to see what they think.

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12147>
_______________________________________

From report at bugs.python.org  Sat Jun 18 22:11:13 2011
From: report at bugs.python.org (Martin Marcher)
Date: Sat, 18 Jun 2011 20:11:13 +0000
Subject: [issue12360] Doc Typo
In-Reply-To: <1308427873.33.0.846212256461.issue12360@psf.upfronthosting.co.za>
Message-ID: <1308427873.33.0.846212256461.issue12360@psf.upfronthosting.co.za>


New submission from Martin Marcher <martin at marcher.name>:

Slight typo in the docs.

I don't quite know how to work with mercurial. Hope it'll just work to merge the bitbucket link.

Typo is here: http://docs.python.org/py3k/library/asyncore.html#asyncore.dispatcher.handle_accepted (but also present in tip)

The parameter is named *sock*, but the docs talk about *conn*.

regards
Martin


hg diff -r 9569d8c4c781
diff -r 9569d8c4c781 Doc/library/asyncore.rst
--- a/Doc/library/asyncore.rst	Sat Jun 18 13:02:42 2011 -0400
+++ b/Doc/library/asyncore.rst	Sat Jun 18 22:08:42 2011 +0200
@@ -157,7 +157,7 @@
 
       Called on listening channels (passive openers) when a connection has been
       established with a new remote endpoint that has issued a :meth:`connect`
-      call for the local endpoint.  *conn* is a *new* socket object usable to
+      call for the local endpoint.  *sock* is a *new* socket object usable to
       send and receive data on the connection, and *address* is the address
       bound to the socket on the other end of the connection.

----------
assignee: docs at python
components: Documentation
hgrepos: 30
messages: 138594
nosy: docs at python, martin.marcher
priority: normal
severity: normal
status: open
title: Doc Typo
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12360>
_______________________________________

From report at bugs.python.org  Sat Jun 18 22:12:49 2011
From: report at bugs.python.org (Martin Marcher)
Date: Sat, 18 Jun 2011 20:12:49 +0000
Subject: [issue12360] Doc Typo
In-Reply-To: <1308427873.33.0.846212256461.issue12360@psf.upfronthosting.co.za>
Message-ID: <1308427969.04.0.979129128846.issue12360@psf.upfronthosting.co.za>


Martin Marcher <martin at marcher.name> added the comment:

Fix repo link :(

----------
hgrepos: +31

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12360>
_______________________________________

From report at bugs.python.org  Sat Jun 18 22:13:20 2011
From: report at bugs.python.org (Martin Marcher)
Date: Sat, 18 Jun 2011 20:13:20 +0000
Subject: [issue12360] Doc Typo
In-Reply-To: <1308427873.33.0.846212256461.issue12360@psf.upfronthosting.co.za>
Message-ID: <1308428000.5.0.453464734076.issue12360@psf.upfronthosting.co.za>


Changes by Martin Marcher <martin at marcher.name>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22405/2d9bc44963f6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12360>
_______________________________________

From report at bugs.python.org  Sat Jun 18 22:49:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Jun 2011 20:49:41 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1308430181.05.0.417738340825.issue12167@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I changed test test to use a subprocess:

Yes, in packaging.  I replied to an earlier question about distutils:

>>> I could not find any test in distutils/tests that imports extension modules.
>> test_build_ext builds and imports xx.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Sat Jun 18 22:50:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Jun 2011 20:50:41 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1308430241.85.0.832016262902.issue12326@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

IOW, they should check os.name == 'posix'?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Jun 18 22:52:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Jun 2011 20:52:21 +0000
Subject: [issue12226] use HTTPS by default for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1308430341.06.0.763532296243.issue12226@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Because it?s not finished.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Sat Jun 18 22:52:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Jun 2011 20:52:38 +0000
Subject: [issue12357] Python dist modifications for secure PyPI uploads
In-Reply-To: <1308389135.03.0.407441500692.issue12357@psf.upfronthosting.co.za>
Message-ID: <1308430358.43.0.722438249765.issue12357@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +use HTTPS by default for uploading packages to pypi, validate server certificate when uploading packages to PyPI

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12357>
_______________________________________

From report at bugs.python.org  Sat Jun 18 22:54:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Jun 2011 20:54:25 +0000
Subject: [issue12358] validate server certificate when uploading packages to
	PyPI
In-Reply-To: <1308389640.44.0.96724424469.issue12358@psf.upfronthosting.co.za>
Message-ID: <1308430465.79.0.270601844453.issue12358@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m going to close this report as a duplicate.  The discussion about validation is already started on the other report, and I don?t want to commit first one patch with false security (use HTTPS), then a patch to validate: they should be one patch IMO.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> use HTTPS by default for uploading packages to pypi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12358>
_______________________________________

From report at bugs.python.org  Sat Jun 18 22:55:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Jun 2011 20:55:00 +0000
Subject: [issue12357] Python dist modifications for secure PyPI uploads
In-Reply-To: <1308389135.03.0.407441500692.issue12357@psf.upfronthosting.co.za>
Message-ID: <1308430500.46.0.828809774638.issue12357@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See #12358 for why I think we don?t need three reports for this.

----------
dependencies:  -use HTTPS by default for uploading packages to pypi, validate server certificate when uploading packages to PyPI
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> use HTTPS by default for uploading packages to pypi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12357>
_______________________________________

From report at bugs.python.org  Sat Jun 18 23:27:38 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 18 Jun 2011 21:27:38 +0000
Subject: [issue12226] use HTTPS by default for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1308432458.89.0.232177090032.issue12226@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

What is left?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Sat Jun 18 23:28:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Jun 2011 21:28:18 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1308432498.15.0.775896898147.issue8668@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Higery asked me why I recommended/asked that the .dist-info directory should be built in the build directory: ?don't you feel it's a bit strange because we actually don't build the source except for some .c/.cpp files, but create a build directory??

There are a few converging reasons for that.  Maybe a develop expert user will disagree with me, but I think that together they make a good case.

The first reason is symmetry.  The test command (http://docs.python.org/dev/packaging/commandref#test) needs to have the Python code in the build directory on sys.path, so that if you use build-time 2to3 conversion (currently undocumented :( apart from a line in http://docs.python.org/dev/packaging/setupcfg#command-sections), the tests need to find the 3.x code in the build dir, not the 2.x code in the project dir.  I think that since we already put the build dir on sys.path to run tests, we might as well follow the same idead and put the dist-info dir in the build dir.  The test command will then automatically have access to dist-info (see #12302), and other commands and tools can learn to look for dist-info in the build dir.

The second reason is that I think we need to separate build_distinfo from install_distinfo (#12279).  If we do this, then the new command has to write in the build dir, just like all other build_* commands (with possible exceptions).

The third reason is that I don?t like that every project that uses setuptools needs to add ProjectName.egg-info in the VCS ignore file (like .hgignore); if we use the build dir, our generated files are already covered by the ignore of the build dir.  (This makes me think that we may want to move MANIFEST to the build dir.)

I hope my reasons are clearer now; let me know if I did not explain something clearly enough, or if you disagree :)

----------
nosy: +carljm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Sat Jun 18 23:29:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Jun 2011 21:29:41 +0000
Subject: [issue12226] use HTTPS by default for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1308432581.4.0.622169668795.issue12226@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Certificate checking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Sat Jun 18 23:30:51 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 18 Jun 2011 21:30:51 +0000
Subject: [issue12358] validate server certificate when uploading packages to
	PyPI
In-Reply-To: <1308389640.44.0.96724424469.issue12358@psf.upfronthosting.co.za>
Message-ID: <1308432651.22.0.194406418402.issue12358@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

That's two separate tickets. I intentionally wasted my time opening several of them to avoid making issues overcomplicated, so that they are manageable for review and won't slip from the next release.

Ping me in GTalk if you want to discuss it.

----------
resolution: duplicate -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12358>
_______________________________________

From report at bugs.python.org  Sat Jun 18 23:32:56 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 18 Jun 2011 21:32:56 +0000
Subject: [issue12358] validate server certificate when uploading packages to
	PyPI
In-Reply-To: <1308389640.44.0.96724424469.issue12358@psf.upfronthosting.co.za>
Message-ID: <1308432776.52.0.748010189198.issue12358@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Mind you that HTTPS access without certificate validation is not a false security - even without certificate it provides a good protection from passive attacks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12358>
_______________________________________

From report at bugs.python.org  Sat Jun 18 23:33:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Jun 2011 21:33:28 +0000
Subject: [issue12358] validate server certificate when uploading packages to
	PyPI
In-Reply-To: <1308389640.44.0.96724424469.issue12358@psf.upfronthosting.co.za>
Message-ID: <1308432808.0.0.597740177304.issue12358@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t see why you think we need two tickets.  I will not commit the partial patch from the other bug, and I don?t think it?s overcomplicated to think about ?use HTTPS with certificate checking?.

About GTalk/Jabber: I prefer to discuss openly on this bug tracker or mailing lists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12358>
_______________________________________

From report at bugs.python.org  Sat Jun 18 23:43:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Jun 2011 21:43:28 +0000
Subject: [issue9436] test_sysconfig failure
In-Reply-To: <1280591591.84.0.476083865565.issue9436@psf.upfronthosting.co.za>
Message-ID: <1308433408.54.0.0451981030233.issue9436@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I wonder if this is similar to #9437.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9436>
_______________________________________

From report at bugs.python.org  Sat Jun 18 23:45:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Jun 2011 21:45:25 +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: <1308433525.94.0.847943830019.issue6087@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also #12141.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6087>
_______________________________________

From report at bugs.python.org  Sat Jun 18 23:45:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Jun 2011 21:45:45 +0000
Subject: [issue12141] sysconfig.get_config_vars('srcdir') fails in specific
	cases
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1308433545.21.0.865641265778.issue12141@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also #10764.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Sat Jun 18 23:47:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Jun 2011 21:47:37 +0000
Subject: [issue11602] python-config code should be in sysconfig
In-Reply-To: <1300475478.49.0.935411639754.issue11602@psf.upfronthosting.co.za>
Message-ID: <1308433657.38.0.91226072647.issue11602@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 on the request.  I don?t think it can go in 3.2, though.  I?ll propose a patch, this will let me learn more about the flags.

> Also, it begs the question why distutils doesn't use the same code in
> its compiler class, or even in customize_compiler()...

Certainly because distutils pre-dates python-config.  In packaging, we should certainly use sysconfig functions.

----------
components: +Distutils2, Library (Lib) -Distutils
nosy: +alexis
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11602>
_______________________________________

From report at bugs.python.org  Sat Jun 18 23:47:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Jun 2011 21:47:46 +0000
Subject: [issue11602] python-config code should be in sysconfig
In-Reply-To: <1300475478.49.0.935411639754.issue11602@psf.upfronthosting.co.za>
Message-ID: <1308433666.54.0.12885943099.issue11602@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11602>
_______________________________________

From report at bugs.python.org  Sat Jun 18 23:53:01 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 18 Jun 2011 21:53:01 +0000
Subject: [issue12358] validate server certificate when uploading packages to
	PyPI
In-Reply-To: <1308389640.44.0.96724424469.issue12358@psf.upfronthosting.co.za>
Message-ID: <1308433981.87.0.386267651085.issue12358@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

If tickets are small and easy, they can be committed faster. I wouldn't open another one if this small patch was committed in time. As I already explained, adding certificate check to HTTPS is a further security enhancement, and here is the report for it to not forget and discuss further security issues. It is not 'incomplete'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12358>
_______________________________________

From report at bugs.python.org  Sat Jun 18 23:55:34 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 18 Jun 2011 21:55:34 +0000
Subject: [issue12226] use HTTPS by default for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1308434134.17.0.921998735366.issue12226@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

That's the issue12358.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Sat Jun 18 23:57:24 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 18 Jun 2011 21:57:24 +0000
Subject: [issue12357] Python dist modifications for secure PyPI uploads
In-Reply-To: <1308389135.03.0.407441500692.issue12357@psf.upfronthosting.co.za>
Message-ID: <1308434244.81.0.969400031017.issue12357@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Why don't you want to wait for the third opinion before judging tickets on your own. Do you understand that this creates a conflict?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12357>
_______________________________________

From report at bugs.python.org  Sat Jun 18 23:57:57 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 18 Jun 2011 21:57:57 +0000
Subject: [issue12357] Python dist modifications for secure PyPI uploads
In-Reply-To: <1308389135.03.0.407441500692.issue12357@psf.upfronthosting.co.za>
Message-ID: <1308434277.95.0.329084780568.issue12357@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

See the same issue12358 for the opposite arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12357>
_______________________________________

From report at bugs.python.org  Sun Jun 19 00:02:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 18 Jun 2011 22:02:30 +0000
Subject: [issue12357] Python dist modifications for secure PyPI uploads
In-Reply-To: <1308389135.03.0.407441500692.issue12357@psf.upfronthosting.co.za>
Message-ID: <1308434550.74.0.959617484803.issue12357@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Stefan Krah, Fred L. Drake and Antoine Pitrou agreed with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12357>
_______________________________________

From report at bugs.python.org  Sun Jun 19 00:34:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Jun 2011 22:34:13 +0000
Subject: [issue12357] Python dist modifications for secure PyPI uploads
In-Reply-To: <1308389135.03.0.407441500692.issue12357@psf.upfronthosting.co.za>
Message-ID: <1308436453.96.0.73904745346.issue12357@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Furthermore, ?ric is the one who is going to commit the patch, and therefore these tracker issues should be organized to provide him with maximum productivity.  If he thinks this should be closed, then it should be closed.

If you wish to continue to argue that the change to https should be made without validation, then you can argue it on the other ticket and/or python-dev.

----------
nosy: +r.david.murray
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12357>
_______________________________________

From report at bugs.python.org  Sun Jun 19 00:41:57 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 18 Jun 2011 22:41:57 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1308436917.66.0.415453669749.issue12291@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Sorry I'm being dense, but which file object do you mean?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sun Jun 19 00:59:26 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 18 Jun 2011 22:59:26 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1308436917.66.0.415453669749.issue12291@psf.upfronthosting.co.za>
Message-ID: <BANLkTikgj23SWbJfRLKsqBX=Bd+79exWiA@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/6/18 Vinay Sajip <report at bugs.python.org>:
>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
> Sorry I'm being dense, but which file object do you mean?

The python file object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sun Jun 19 01:28:31 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Jun 2011 23:28:31 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1308439711.38.0.782341808596.issue3067@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

After more thought and investigation, I have changed my opinions on this issue.


Allowing unicode string for locale in 2.7:
Since the module predates unicode strings (it is in 1.5) and since the locale string is passed to a C function, 'string' in the doc can just as well be taken to mean ascii byte string only, as the code requires. As far as I know, unicode is never needed. Allowing such could be considered a feature addition, which is not allowed for 2.7. So I would reject the OP's request (and have hence changed the title).

Expected failure cases could be added to test_locale.py.


Options for locale name:
As I remember, multiple assignments in 1.5, as in

def _build_localename(localetuple):
    language, encoding = localetuple

required a tuple on the right and was called 'tuple unpacking'.
Now, any iterable producing 2 items works; Rather than change to code to check that 'localetuple' really is a tuple (which could break code and the principle of duck-typing), I think the doc should be updated to

"If locale is specified, it may be a None, a string, or an iterable producing two strings, language code and encoding."

This is not a feature addition but a recognition of a new feature added versions ago. The parameter name in the private function should then be shortened to just 'locale'.

Test cases with non-tuples could be added if not present now.


Exception message:
The current message arises from setlocale assuming that a 'locale' that is neither None or a string is a valid iterable for a call to _build_localename. A strings of the wrong type produces too many items and hence the obscure message.

Python is known to be inconsistent in its usage of ValueError versus TypeError for builtin function args. Guido has said to leave inconsistencies rather than break code. So I retract the ValueError to TypeError suggestion.

The accompanying messages, however, can be improved. The lines above that fails could be wrapped with
    try:
        language, encoding = locale
    except ValueError:
        raise ValueError("Locale must be None, a string, or an iterable of two strings -- language code, encoding -- not {}".format(locale))

The scope of the wrapper could be extended to the entire function so that failure of
        return language + '.' + encoding
would also be caught. Failure would happen if locale produced 2 non-strings items, so that the double assignment 'worked', but the string concatenation failed.

A complication: the doc says
"exception locale.Error 
Exception raised when setlocale() fails.

locale.setlocale(category, locale=None) 
...If the modification of the locale fails, the exception Error is raised."

So it seems that either a) the wrapper above should raise Error instead, or the doc could more clearly say "Exception raised when the locale passed to setlocale is not recognized."

----------
nosy: +lemburg, loewis
title: setlocale fails with unicode strings on Py2 and with byte strings on Py3 -> setlocale error message is confusing
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Sun Jun 19 01:37:00 2011
From: report at bugs.python.org (Jacob Perkins)
Date: Sat, 18 Jun 2011 23:37:00 +0000
Subject: [issue12361] Memory Leak in File Logging
In-Reply-To: <1308440220.9.0.536544421463.issue12361@psf.upfronthosting.co.za>
Message-ID: <1308440220.9.0.536544421463.issue12361@psf.upfronthosting.co.za>


New submission from Jacob Perkins <japerk at gmail.com>:

I have a custom proxy server that was using a WatchedFileHandler for logging requests (the files were rotated with logrotate). It was leaking memory, and I had to use supervisord's memmon plugin to restart it whenever it exceed a certain threshold. I eventually tried disabling the WatchedFileHandler, and memory usage flattened out. I also have a StreamHandler logging the requests, so I have to conclude the leak is in WatchedFileHandler or FileHandler. This is with Python 2.6.6.

----------
components: Library (Lib)
messages: 138620
nosy: japerk
priority: normal
severity: normal
status: open
title: Memory Leak in File Logging
type: resource usage
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12361>
_______________________________________

From report at bugs.python.org  Sun Jun 19 01:42:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 18 Jun 2011 23:42:47 +0000
Subject: [issue6771] Curses.wrapper: documentation/implementation error
In-Reply-To: <1251099236.05.0.0799674766136.issue6771@psf.upfronthosting.co.za>
Message-ID: <E1QY5A5-0007io-Kk@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset dc78ab3f7bc5 by R David Murray in branch '2.7':
#6771: fix docs: curses.wrapper is exposed as a function, not a module
http://hg.python.org/cpython/rev/dc78ab3f7bc5

New changeset f9b4cfc19264 by R David Murray in branch '3.2':
#6771: fix docs: curses.wrapper is exposed as a function, not a module
http://hg.python.org/cpython/rev/f9b4cfc19264

New changeset bb5e950ebb04 by R David Murray in branch 'default':
merge #6771: fix docs: curses.wrapper is exposed as a function, not a module
http://hg.python.org/cpython/rev/bb5e950ebb04

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6771>
_______________________________________

From report at bugs.python.org  Sun Jun 19 02:21:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 19 Jun 2011 00:21:30 +0000
Subject: [issue6771] Curses.wrapper: documentation/implementation error
In-Reply-To: <1251099236.05.0.0799674766136.issue6771@psf.upfronthosting.co.za>
Message-ID: <E1QY5lX-0001be-Qi@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9c96c3adbcd1 by R David Murray in branch 'default':
#6771: Move wrapper function into __init__ and eliminate wrapper module
http://hg.python.org/cpython/rev/9c96c3adbcd1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6771>
_______________________________________

From report at bugs.python.org  Sun Jun 19 02:22:09 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Jun 2011 00:22:09 +0000
Subject: [issue6771] Curses.wrapper: documentation/implementation error
In-Reply-To: <1251099236.05.0.0799674766136.issue6771@psf.upfronthosting.co.za>
Message-ID: <1308442929.97.0.0839492754609.issue6771@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6771>
_______________________________________

From report at bugs.python.org  Sun Jun 19 02:42:47 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 19 Jun 2011 00:42:47 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <BANLkTikgj23SWbJfRLKsqBX=Bd+79exWiA@mail.gmail.com>
Message-ID: <675286.42112.qm@web25802.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Benjamin Peterson <benjamin at python.org> added the  comment:
> >  Vinay Sajip <vinay_sajip at yahoo.co.uk> added the  comment:
> >
> > Sorry I'm being dense, but which file object do you  mean?
> 
> The python file  object.

Do you mean special-case handling of the circumstance when the file-like object 
being marshalled from is actually a file? The existing code paths (from when 
marshal.load expected only to work with Python file objects) use FILE *, and 
these are used by other code to read magic numbers etc. I believe. Or perhaps 
I'm still misunderstanding what you're getting at.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sun Jun 19 03:02:49 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 19 Jun 2011 01:02:49 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <675286.42112.qm@web25802.mail.ukl.yahoo.com>
Message-ID: <BANLkTimAxmw21U4wjYa--ziBB1fdY47zoQ@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/6/18 Vinay Sajip <report at bugs.python.org>:
>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
>> Benjamin Peterson <benjamin at python.org> added the ?comment:
>> > ?Vinay Sajip <vinay_sajip at yahoo.co.uk> added the ?comment:
>> >
>> > Sorry I'm being dense, but which file object do you ?mean?
>>
>> The python file ?object.
>
> Do you mean special-case handling of the circumstance when the file-like object
> being marshalled from is actually a file? The existing code paths (from when
> marshal.load expected only to work with Python file objects) use FILE *, and
> these are used by other code to read magic numbers etc. I believe. Or perhaps
> I'm still misunderstanding what you're getting at.

When python uses dump() or load() with a file object, you can call
fileno() (and then fopen?) to use it like a C-file object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sun Jun 19 03:22:24 2011
From: report at bugs.python.org (Martin Marcher)
Date: Sun, 19 Jun 2011 01:22:24 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1308446544.76.0.628733930516.issue4111@psf.upfronthosting.co.za>


Changes by Martin Marcher <martin at marcher.name>:


----------
nosy: +serverhorror

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Sun Jun 19 06:21:04 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Jun 2011 04:21:04 +0000
Subject: [issue12361] Memory Leak in File Logging
In-Reply-To: <1308440220.9.0.536544421463.issue12361@psf.upfronthosting.co.za>
Message-ID: <1308457264.03.0.611461458885.issue12361@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12361>
_______________________________________

From report at bugs.python.org  Sun Jun 19 10:41:13 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 19 Jun 2011 08:41:13 +0000
Subject: [issue12361] Memory Leak in File Logging
In-Reply-To: <1308440220.9.0.536544421463.issue12361@psf.upfronthosting.co.za>
Message-ID: <1308472873.5.0.213429654003.issue12361@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12361>
_______________________________________

From report at bugs.python.org  Sun Jun 19 11:17:10 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 19 Jun 2011 09:17:10 +0000
Subject: [issue12278] Core mentorship mention in the devguide
In-Reply-To: <1307445407.08.0.276007268612.issue12278@psf.upfronthosting.co.za>
Message-ID: <1308475030.8.0.539689284527.issue12278@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12278>
_______________________________________

From report at bugs.python.org  Sun Jun 19 13:39:11 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 19 Jun 2011 11:39:11 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1308483551.26.0.94674905556.issue12291@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The problem with calling fileno() and fdopen() is that you bypass the buffering information held in BufferedIOReader. The first call works, but the FILE * pointer is now positioned at 4K, rather than just past the end of the object just read. The next call fails.

I verified that calling f.tell() after marshal.load(f) returns 4096, rather than just the size of the object read by the load().

Just to be clear, here's what I did in marshal_load:

    int is_file = 0;
    int fd;

    data = PyObject_CallMethod(f, "fileno", "");
    if (data == NULL)
        PyErr_Clear();
    else {
        fd = PyLong_AsLong(data);
        Py_DECREF(data);
        is_file = 1;
    }
    if (is_file) {
        rf.readable = NULL;
        rf.fp = fdopen(fd, "rb");
    }
    else {
        /* what I was doing before to set up rf */
    }
    /* and on to the read_object call */

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sun Jun 19 13:54:29 2011
From: report at bugs.python.org (CrouZ)
Date: Sun, 19 Jun 2011 11:54:29 +0000
Subject: [issue12362] General Windows stdout redirection not working
In-Reply-To: <1308484469.07.0.183679087602.issue12362@psf.upfronthosting.co.za>
Message-ID: <1308484469.07.0.183679087602.issue12362@psf.upfronthosting.co.za>


New submission from CrouZ <alfred.theorin at gmail.com>:

Steps to repeat:
* Create the script foo.py consisting of the line: print("foo")
* Run: foo.py > bar

Behavior:
 2.7.2: The file bar is created but empty. Prints the following message on exit:

close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr

 3.1.4: The file bar is created but empty. No printouts indicating that something went wrong.

Expected behavior:
 All: The file bar has the content foo.

Additional information:
 sys.stdout, and probably also sys.stderr, do not appear to be set up properly.
  2.7.2: stdout is set to a file but performing any operations on it throws the exception: IOError: [Errno 9] Bad file descriptor
  3.1.4: stdout is set to None

Workaround:
 All: python foo.py > bar

Used software:
 Windows 7 Ultimate SP1 x64 (6.1.7601)
 Python 2.7.2 and 3.1.4 installed with the msi-installer including Registering Extensions.

----------
components: Windows
messages: 138626
nosy: CrouZ
priority: normal
severity: normal
status: open
title: General Windows stdout redirection not working
type: crash
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12362>
_______________________________________

From report at bugs.python.org  Sun Jun 19 13:54:44 2011
From: report at bugs.python.org (CrouZ)
Date: Sun, 19 Jun 2011 11:54:44 +0000
Subject: [issue12362] General Windows stdout redirection not working
In-Reply-To: <1308484469.07.0.183679087602.issue12362@psf.upfronthosting.co.za>
Message-ID: <1308484484.24.0.740479821485.issue12362@psf.upfronthosting.co.za>


Changes by CrouZ <alfred.theorin at gmail.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12362>
_______________________________________

From report at bugs.python.org  Sun Jun 19 13:54:49 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 19 Jun 2011 11:54:49 +0000
Subject: [issue12361] Memory Leak in File Logging
In-Reply-To: <1308440220.9.0.536544421463.issue12361@psf.upfronthosting.co.za>
Message-ID: <1308484489.6.0.405066776533.issue12361@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Thanks for the report, but more information from the failing system may be needed to find the problem. Although 2.6 does not contain full unit test coverage, the default branch does - and I tested there with resource leak checking turned on, with no leaks being detected. An eyeball inspection fails to show where a leak could be occurring: WatchedFileHandler just makes stat() calls and, if appropriate, calls flush/close on the existing stream and open on the new one.

Test output:

vinay at eta-jaunty:~/projects/python/default$ ./python Lib/test/regrtest.py -R :: test_logging
[1/1] test_logging
beginning 9 repetitions
123456789
.........
1 test OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12361>
_______________________________________

From report at bugs.python.org  Sun Jun 19 13:58:44 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 19 Jun 2011 11:58:44 +0000
Subject: [issue12358] validate server certificate when uploading packages to
	PyPI
In-Reply-To: <1308389640.44.0.96724424469.issue12358@psf.upfronthosting.co.za>
Message-ID: <1308484724.04.0.840130950097.issue12358@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I agree with ?ric: This is a duplicate.

----------
nosy: +skrah
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12358>
_______________________________________

From report at bugs.python.org  Sun Jun 19 15:08:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 19 Jun 2011 13:08:00 +0000
Subject: [issue12278] Core mentorship mention in the devguide
In-Reply-To: <1307445407.08.0.276007268612.issue12278@psf.upfronthosting.co.za>
Message-ID: <E1QYHjL-0003Vj-8J@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 144b12d7bb28 by Nick Coghlan in branch 'default':
ACKS update for devguide patch (closes #12278)
http://hg.python.org/cpython/rev/144b12d7bb28

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12278>
_______________________________________

From report at bugs.python.org  Sun Jun 19 16:38:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Jun 2011 14:38:53 +0000
Subject: [issue12362] General Windows stdout redirection not working
In-Reply-To: <1308484469.07.0.183679087602.issue12362@psf.upfronthosting.co.za>
Message-ID: <1308494333.62.0.372974629794.issue12362@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The file association for .py is pythonw, which does exactly as you say, intentionally, so as to avoid problems with windows when running a GUI application.  My understanding is that this caters to the most common use case on Windows: double clicking a .py file launching a Python GUI application.  When running a python script in the console, use 'python', as in your example (or manually change your file association).

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12362>
_______________________________________

From report at bugs.python.org  Sun Jun 19 16:45:43 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 19 Jun 2011 14:45:43 +0000
Subject: [issue11637] Add cwd to sys.path for hooks
In-Reply-To: <1300828230.79.0.355779213126.issue11637@psf.upfronthosting.co.za>
Message-ID: <1308494743.59.0.495797558523.issue11637@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
hgrepos: +32

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11637>
_______________________________________

From report at bugs.python.org  Sun Jun 19 16:50:51 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 19 Jun 2011 14:50:51 +0000
Subject: [issue11637] Add cwd to sys.path for hooks
In-Reply-To: <1300828230.79.0.355779213126.issue11637@psf.upfronthosting.co.za>
Message-ID: <1308495051.96.0.298250685413.issue11637@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11637>
_______________________________________

From report at bugs.python.org  Sun Jun 19 16:54:54 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 19 Jun 2011 14:54:54 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1308483551.26.0.94674905556.issue12291@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=t1PaUdmDOj97NuvpCP+DyLMgLkQ@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/6/19 Vinay Sajip <report at bugs.python.org>:
>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
> The problem with calling fileno() and fdopen() is that you bypass the buffering information held in BufferedIOReader. The first call works, but the FILE * pointer is now positioned at 4K, rather than just past the end of the object just read. The next call fails.

But presumably once you have the fd, you can llseek().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sun Jun 19 17:02:13 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 19 Jun 2011 15:02:13 +0000
Subject: [issue11690] Devguide: Add "communication" FAQ
In-Reply-To: <1301188192.33.0.9529618781.issue11690@psf.upfronthosting.co.za>
Message-ID: <1308495733.31.0.413093945233.issue11690@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Comms FAQ: http://hg.python.org/devguide/rev/f1ebfb53437f
Devguide note: http://hg.python.org/devguide/rev/5ab42baba771

----------
resolution:  -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11690>
_______________________________________

From report at bugs.python.org  Sun Jun 19 17:02:53 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 19 Jun 2011 15:02:53 +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: <1308495773.61.0.47168073029.issue11795@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Enhanced committer guidelines: http://hg.python.org/devguide/rev/774fb024b152

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11795>
_______________________________________

From report at bugs.python.org  Sun Jun 19 17:03:54 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 19 Jun 2011 15:03:54 +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: <1308495834.4.0.509601262281.issue11795@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11795>
_______________________________________

From report at bugs.python.org  Sun Jun 19 17:04:11 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 19 Jun 2011 15:04:11 +0000
Subject: [issue11690] Devguide: Add "communication" FAQ
In-Reply-To: <1301188192.33.0.9529618781.issue11690@psf.upfronthosting.co.za>
Message-ID: <1308495851.07.0.428089190668.issue11690@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11690>
_______________________________________

From report at bugs.python.org  Sun Jun 19 17:28:35 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 19 Jun 2011 15:28:35 +0000
Subject: [issue12362] General Windows stdout redirection not working
In-Reply-To: <1308484469.07.0.183679087602.issue12362@psf.upfronthosting.co.za>
Message-ID: <1308497315.02.0.329827373726.issue12362@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

"The file association for .py is pythonw"
Really? http://docs.python.org/using/windows.html#executing-scripts

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12362>
_______________________________________

From report at bugs.python.org  Sun Jun 19 17:32:46 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 19 Jun 2011 15:32:46 +0000
Subject: [issue12362] General Windows stdout redirection not working
In-Reply-To: <1308484469.07.0.183679087602.issue12362@psf.upfronthosting.co.za>
Message-ID: <1308497566.93.0.231060560654.issue12362@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

IMO the cause is actually the same as the one for issue9390, i.e. a bug in the Windows console.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12362>
_______________________________________

From report at bugs.python.org  Sun Jun 19 17:43:11 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 19 Jun 2011 15:43:11 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1308498191.86.0.698855233158.issue12291@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This seems a bit hacky, and I'm not sure how reliable it is. I added this after the read_object call:

    if (is_file) {
        PyObject * newpos;
        int cp, np;

        cp = ftell(rf.fp);
        newpos = PyObject_CallMethod(f, "seek", "ii", cp, SEEK_SET);
        assert(newpos != NULL);
        np = PyLong_AsLong(newpos);
        Py_DECREF(newpos);
        assert(cp == np);
    }

When I run the code lots of times, I sometimes get assertion failures at the

assert(newpos != NULL)

line. It's not an EOF condition thing, necessarily: I do get expected behaviour at least sometimes when seeking to the end of file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sun Jun 19 17:45:46 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 19 Jun 2011 15:45:46 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1308498191.86.0.698855233158.issue12291@psf.upfronthosting.co.za>
Message-ID: <BANLkTikOz82ah-g4wz_O5q2j+h4C6=_KOQ@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/6/19 Vinay Sajip <report at bugs.python.org>:
>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
> This seems a bit hacky, and I'm not sure how reliable it is. I added this after the read_object call:
>
> ? ?if (is_file) {
> ? ? ? ?PyObject * newpos;
> ? ? ? ?int cp, np;
>
> ? ? ? ?cp = ftell(rf.fp);
> ? ? ? ?newpos = PyObject_CallMethod(f, "seek", "ii", cp, SEEK_SET);

Why not 0?

> ? ? ? ?assert(newpos != NULL);
> ? ? ? ?np = PyLong_AsLong(newpos);
> ? ? ? ?Py_DECREF(newpos);
> ? ? ? ?assert(cp == np);
> ? ?}
>
> When I run the code lots of times, I sometimes get assertion failures at the
>
> assert(newpos != NULL)

That's because the call is failing. Why?

>
> line. It's not an EOF condition thing, necessarily: I do get expected behaviour at least sometimes when seeking to the end of file.
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sun Jun 19 17:57:09 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Jun 2011 15:57:09 +0000
Subject: [issue12362] General Windows stdout redirection not working
In-Reply-To: <1308484469.07.0.183679087602.issue12362@psf.upfronthosting.co.za>
Message-ID: <1308499029.77.0.522358700745.issue12362@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, I should have known better than to rely on a memory instead of checking, since I don't use Windows much.  My apologies.

----------
dependencies: +Error in sys.excepthook on windows when redirecting output of the script
resolution: invalid -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12362>
_______________________________________

From report at bugs.python.org  Sun Jun 19 17:59:51 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Jun 2011 15:59:51 +0000
Subject: [issue12362] General Windows stdout redirection not working
In-Reply-To: <1308484469.07.0.183679087602.issue12362@psf.upfronthosting.co.za>
Message-ID: <1308499191.56.0.659029755007.issue12362@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
dependencies:  -Error in sys.excepthook on windows when redirecting output of the script
superseder:  -> Error in sys.excepthook on windows when redirecting output of the script

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12362>
_______________________________________

From report at bugs.python.org  Sun Jun 19 18:12:24 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Jun 2011 16:12:24 +0000
Subject: [issue10454] Clarify compileall command-line options
In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>
Message-ID: <1308499944.49.0.0078038174769.issue10454@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looks fine except for your changes to the parenthesized defaults.  Those should be '0' and 'False' for 2.7 and 3.x, respectively, since that's what they areally are.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10454>
_______________________________________

From report at bugs.python.org  Sun Jun 19 18:24:51 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 19 Jun 2011 16:24:51 +0000
Subject: [issue12346] Python source code build fails with old mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1308500691.41.0.325914203066.issue12346@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

So, it seems the problem is not actually that the build depends on mercurial, it's that it fails with ancient mercurials.

----------
title: Python source code build (release) depends on mercurial -> Python source code build fails with old mercurial

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12346>
_______________________________________

From report at bugs.python.org  Sun Jun 19 18:26:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Jun 2011 16:26:22 +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: <1308500782.27.0.230011863118.issue11795@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that the older tradition was to *not* mention the contributor in NEWS (NEWS was just technical notes), but to mention them in the checkin message (and What's New, for things that make the What's New cut).  However, since we can't edit checkin messages post-commit like we could with SVN, I suppose this new convention (that some people have been following since well before the switchover...) is more practical.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11795>
_______________________________________

From report at bugs.python.org  Sun Jun 19 18:36:45 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Jun 2011 16:36:45 +0000
Subject: [issue12346] Python source code build fails with old mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1308501405.63.0.634069425643.issue12346@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Only if Ralf's patch is applied to all branches.  Otherwise the make step reports "abort: repository . not found!", which most users will ignore but a few will report here.  It looks from Ralf's quoted changeset like it was only applied to default, but frankly I'm not comfortable enough with mercurial yet to be able to tell.

If Ralf's patch is applied, then the lack of a repository would cause the old hg to not get called.  If someone *has* a repository in the build dir, I think we can assume they used a new enough hg to check it out...and if they didn't, that *is* a bug in their setup they should fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12346>
_______________________________________

From report at bugs.python.org  Sun Jun 19 18:38:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Jun 2011 16:38:55 +0000
Subject: [issue12346] Python source code build fails with old mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1308501535.58.0.746992515621.issue12346@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yes, it was committed to default.

> I think we can assume they used a new enough hg to check it out...and
> if they didn't, that *is* a bug in their setup they should fix.
Agreed.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12346>
_______________________________________

From report at bugs.python.org  Sun Jun 19 19:00:26 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 19 Jun 2011 17:00:26 +0000
Subject: [issue12255] A few changes to .*ignore
In-Reply-To: <1307119345.93.0.971452096543.issue12255@psf.upfronthosting.co.za>
Message-ID: <1308502826.29.0.547747001838.issue12255@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

+libpython*.so*  is fine, but please don't remove the rej and orig. By convention and practice, those files are meant to be in .ignore files to prevent accidental checkins.  Usually when the conflict occurs you are notified immediately and you fix them subsequently. Being notified of pending merge by seeing the.rej files in the hg status seems remote to me.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12255>
_______________________________________

From report at bugs.python.org  Sun Jun 19 19:06:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Jun 2011 17:06:59 +0000
Subject: [issue12255] A few changes to .*ignore
In-Reply-To: <1307119345.93.0.971452096543.issue12255@psf.upfronthosting.co.za>
Message-ID: <1308503219.54.0.499455071647.issue12255@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As I've said before, I would vote to not have .rej and .orig in .hgignore.  You can always add them to your personal .hgignore, but I know of no way to tell mercurial "I *don't* want to ignore these files that are in the repo .hgignore".  If there is such a way I'll be happy with that.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12255>
_______________________________________

From report at bugs.python.org  Sun Jun 19 19:09:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Jun 2011 17:09:46 +0000
Subject: [issue12255] A few changes to .*ignore
In-Reply-To: <1307119345.93.0.971452096543.issue12255@psf.upfronthosting.co.za>
Message-ID: <1308503386.67.0.3156582921.issue12255@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> By convention and practice, those files are meant to be in .ignore
> files to prevent accidental checkins.

Maybe with other tools.  Mercurial will tell you what new files are to be added in the next commit once to four times, depending on your setup, so I don?t understand how people accidentally commit .rej files (or .svn directories or Mac OS X crap).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12255>
_______________________________________

From report at bugs.python.org  Sun Jun 19 19:21:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Jun 2011 17:21:45 +0000
Subject: [issue12363] test_signal.test_without_siginterrupt() sporadic
	failures on FreeBSD 6.4
In-Reply-To: <1308504105.8.0.100099791428.issue12363@psf.upfronthosting.co.za>
Message-ID: <1308504105.8.0.100099791428.issue12363@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

======================================================================
FAIL: test_siginterrupt_on (test.test_signal.SiginterruptTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_signal.py", line 396, in test_siginterrupt_on
    self.assertTrue(i)
AssertionError: False is not true

http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/1586/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/1587/steps/test/logs/stdio

----------
messages: 138647
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: test_signal.test_without_siginterrupt() sporadic failures on FreeBSD 6.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12363>
_______________________________________

From report at bugs.python.org  Sun Jun 19 19:25:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Jun 2011 17:25:15 +0000
Subject: [issue12364] Timeout (1 hour) in test_concurrent_futures.tearDown()
	on sparc solaris10 gcc 3.x
In-Reply-To: <1308504315.81.0.454658658034.issue12364@psf.upfronthosting.co.za>
Message-ID: <1308504315.81.0.454658658034.issue12364@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

[271/356/1] test_concurrent_futures
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/multiprocessing/queues.py", line 268, in _feed
    send(obj)
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/multiprocessing/connection.py", line 229, in send
    self._send_bytes(memoryview(buf))
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/multiprocessing/connection.py", line 423, in _send_bytes
    self._send(struct.pack("=i", len(buf)))
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/multiprocessing/connection.py", line 392, in _send
    n = write(self._handle, buf)
OSError: [Errno 32] Broken pipe
Timeout (1:00:00)!
Thread 0x00000954:
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/threading.py", line 237 in wait
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/threading.py", line 690 in run
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000953:
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/multiprocessing/forking.py", line 146 in poll
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/multiprocessing/forking.py", line 166 in wait
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/multiprocessing/process.py", line 150 in join
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/concurrent/futures/process.py", line 208 in shutdown_worker
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/concurrent/futures/process.py", line 264 in _queue_management_worker
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/threading.py", line 690 in run
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000001:
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/threading.py", line 237 in wait
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/threading.py", line 851 in join
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/concurrent/futures/process.py", line 395 in shutdown
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_concurrent_futures.py", line 67 in tearDown
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/case.py", line 463 in run
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/case.py", line 514 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 1166 in run
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/support.py", line 1254 in _run_suite
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/support.py", line 1280 in run_unittest
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_concurrent_futures.py", line 628 in test_main
  File "./Lib/test/regrtest.py", line 1043 in runtest_inner
  File "./Lib/test/regrtest.py", line 841 in runtest
  File "./Lib/test/regrtest.py", line 668 in main
  File "./Lib/test/regrtest.py", line 1618 in <module>
*** Error code 1
make: Fatal error: Command failed for target `buildbottest'
program finished with exit code 1

See commit e6e7e42efdc2 of the issue #12310.

----------
components: Tests
messages: 138648
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: Timeout (1 hour) in test_concurrent_futures.tearDown() on sparc solaris10 gcc 3.x
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12364>
_______________________________________

From report at bugs.python.org  Sun Jun 19 19:26:06 2011
From: report at bugs.python.org (Jeff McNeil)
Date: Sun, 19 Jun 2011 17:26:06 +0000
Subject: [issue12365] URLopener should support context manager protocol
In-Reply-To: <1308504365.98.0.668285563314.issue12365@psf.upfronthosting.co.za>
Message-ID: <1308504365.98.0.668285563314.issue12365@psf.upfronthosting.co.za>


New submission from Jeff McNeil <jeff at jmcneil.net>:

Per discussion within Issue10050, URLopener ought to support the context manager protocol. That allows more idiomatic usage and doesn't require calls to contextlib.closing for use with the 'with' statement.

If agreed, I'll create a patch.

----------
components: Library (Lib)
messages: 138649
nosy: mcjeff
priority: normal
severity: normal
status: open
title: URLopener should support context manager protocol
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12365>
_______________________________________

From report at bugs.python.org  Sun Jun 19 19:26:24 2011
From: report at bugs.python.org (Jeff McNeil)
Date: Sun, 19 Jun 2011 17:26:24 +0000
Subject: [issue12365] URLopener should support context manager protocol
In-Reply-To: <1308504365.98.0.668285563314.issue12365@psf.upfronthosting.co.za>
Message-ID: <1308504384.6.0.173167408707.issue12365@psf.upfronthosting.co.za>


Changes by Jeff McNeil <jeff at jmcneil.net>:


----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12365>
_______________________________________

From report at bugs.python.org  Sun Jun 19 19:34:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Jun 2011 17:34:09 +0000
Subject: [issue12365] URLopener should support context manager protocol
In-Reply-To: <1308504365.98.0.668285563314.issue12365@psf.upfronthosting.co.za>
Message-ID: <1308504849.0.0.457459122773.issue12365@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1.

----------
nosy: +eric.araujo
stage:  -> needs patch
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12365>
_______________________________________

From report at bugs.python.org  Sun Jun 19 19:51:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Jun 2011 17:51:40 +0000
Subject: [issue11637] Add cwd to sys.path for hooks
In-Reply-To: <1300828230.79.0.355779213126.issue11637@psf.upfronthosting.co.za>
Message-ID: <1308505900.68.0.167848612376.issue11637@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks, I made slight editions, now I?m improving the docs and will commit shortly.

----------
assignee: tarek -> eric.araujo
stage: needs patch -> commit review
versions: +Python 3.3 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11637>
_______________________________________

From report at bugs.python.org  Sun Jun 19 19:58:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Jun 2011 17:58:01 +0000
Subject: [issue12363] test_signal.test_without_siginterrupt() sporadic
	failures on FreeBSD 6.4
In-Reply-To: <1308504105.8.0.100099791428.issue12363@psf.upfronthosting.co.za>
Message-ID: <1308506281.06.0.289014686512.issue12363@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Seen also on OpenSolaris:

test test_signal failed -- Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_signal.py", line 399, in test_siginterrupt_on
    self.assertTrue(i)
AssertionError: False is not true

http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.x/builds/1443/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12363>
_______________________________________

From report at bugs.python.org  Sun Jun 19 20:16:18 2011
From: report at bugs.python.org (patrick vrijlandt)
Date: Sun, 19 Jun 2011 18:16:18 +0000
Subject: [issue12321] documentation of ElementTree.find
In-Reply-To: <1308351860.94.0.778184033903.issue12321@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=jm0CB2T23GHW5EXK=tbWURji4Zg@mail.gmail.com>


patrick vrijlandt <patrick.vrijlandt at gmail.com> added the comment:

[...] Same as getroot().find(match). [...] ->
[...] For a relative path, this is equivalent to getroot().find(match).
Additionally, this form accepts an absolute path. [...]

This is easy, but might not be a very good solution.

Random thoughts/Points to consider:
It does help the novice in debugging his expressions.
A peculiarity of this implementation is documented.
As others have stated, the whole elementpath documentation within the python
docs is incomplete. Should we document the exception but not the rule?
It makes no real sense to do a an absolute search from an element. However,
it's not ambiguous.
lxml does accept the absolute path search from an element.

Actually, I think it's up to Fredrik to decide.

2011/6/18 Terry J. Reedy <report at bugs.python.org>

>
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
>
> Are you requesting that the doc be changed or the code?
> >From the title, I would infer the doc (which is much easier ;-).
> If so, can you suggest an actual revised text?
>
> ----------
> nosy: +terry.reedy
> stage:  -> needs patch
> versions: +Python 3.3
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12321>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22406/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12321>
_______________________________________
-------------- next part --------------
<span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">[...] Same as getroot().find(match). [...] -&gt;</span><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">[...] For a relative path, this is equivalent to??</span></font><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">getroot().find(match). Additionally, this form accepts an absolute path. [...]</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; ">This is easy, but might not be a very good solution.??</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; ">Random thoughts/</span><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Points to consider:</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">It does help the novice in debugging his expressions.??</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">A peculiarity of this implementation is documented.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">As others have stated, the whole elementpath documentation within the python docs is incomplete. Should we document the exception but not the rule?</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">It makes no real sense to do a an absolute search from an element. However, it&#39;s not ambiguous.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">lxml does accept the absolute path search from an element.</span></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font></div><div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Actually, I think it&#39;s up to Fredrik to decide.??</span></div></div><div>
<span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font><br><div class="gmail_quote">2011/6/18 Terry J. Reedy <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Terry J. Reedy &lt;<a href="mailto:tjreedy at udel.edu">tjreedy at udel.edu</a>&gt; added the comment:<br>
<br>
Are you requesting that the doc be changed or the code?<br>
&gt;From the title, I would infer the doc (which is much easier ;-).<br>
If so, can you suggest an actual revised text?<br>
<br>
----------<br>
nosy: +terry.reedy<br>
stage: ??-&gt; needs patch<br>
versions: +Python 3.3<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/issue12321" target="_blank">http://bugs.python.org/issue12321</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Sun Jun 19 20:44:42 2011
From: report at bugs.python.org (Darren Dale)
Date: Sun, 19 Jun 2011 18:44:42 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1308509082.83.0.981078359539.issue11610@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

Here is attempt #4. This patch extends the property, classmethod and staticmethod builtins with an __isabstractmethod__ descriptor. Docs and tests are updated as well. "make test" runs without failures. This is my first real attempt with the C-API, and I think I am finally over the learning curve, but comments would be greatly appreciated.

----------
Added file: http://bugs.python.org/file22407/abc_descriptor.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun Jun 19 20:44:58 2011
From: report at bugs.python.org (Darren Dale)
Date: Sun, 19 Jun 2011 18:44:58 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1308509098.94.0.894902518725.issue11610@psf.upfronthosting.co.za>


Changes by Darren Dale <dsdale24 at gmail.com>:


Removed file: http://bugs.python.org/file21307/issue11610.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun Jun 19 20:45:03 2011
From: report at bugs.python.org (Darren Dale)
Date: Sun, 19 Jun 2011 18:45:03 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1308509103.06.0.338917639704.issue11610@psf.upfronthosting.co.za>


Changes by Darren Dale <dsdale24 at gmail.com>:


Removed file: http://bugs.python.org/file21375/issue11610_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun Jun 19 20:50:09 2011
From: report at bugs.python.org (Darren Dale)
Date: Sun, 19 Jun 2011 18:50:09 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1308509409.54.0.400301154366.issue11610@psf.upfronthosting.co.za>


Changes by Darren Dale <dsdale24 at gmail.com>:


Removed file: http://bugs.python.org/file22323/abc_descriptors.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun Jun 19 21:47:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 19 Jun 2011 19:47:22 +0000
Subject: [issue11637] Add cwd to sys.path for hooks
In-Reply-To: <1300828230.79.0.355779213126.issue11637@psf.upfronthosting.co.za>
Message-ID: <E1QYNxo-00059Y-Rz@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b732b02bd0ba by ?ric Araujo in branch 'default':
packaging: Add the project directory to sys.path to support local setup hooks.
http://hg.python.org/cpython/rev/b732b02bd0ba

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11637>
_______________________________________

From report at bugs.python.org  Sun Jun 19 21:48:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Jun 2011 19:48:01 +0000
Subject: [issue11637] Add cwd to sys.path for hooks
In-Reply-To: <1300828230.79.0.355779213126.issue11637@psf.upfronthosting.co.za>
Message-ID: <1308512881.45.0.426671914597.issue11637@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11637>
_______________________________________

From report at bugs.python.org  Sun Jun 19 21:57:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Jun 2011 19:57:26 +0000
Subject: [issue2983] Ttk support for Tkinter
In-Reply-To: <1211911032.63.0.360625687085.issue2983@psf.upfronthosting.co.za>
Message-ID: <1308513446.06.0.198089630298.issue2983@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The 2.7 docs are missing a versionadded directive.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2983>
_______________________________________

From report at bugs.python.org  Sun Jun 19 22:09:32 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 19 Jun 2011 20:09:32 +0000
Subject: [issue11637] Add cwd to sys.path for hooks
In-Reply-To: <1300828230.79.0.355779213126.issue11637@psf.upfronthosting.co.za>
Message-ID: <1308514172.28.0.673086961065.issue11637@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22408/8b9da1557ad2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11637>
_______________________________________

From report at bugs.python.org  Sun Jun 19 22:13:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Jun 2011 20:13:34 +0000
Subject: [issue11637] Add cwd to sys.path for hooks
In-Reply-To: <1300828230.79.0.355779213126.issue11637@psf.upfronthosting.co.za>
Message-ID: <1308514414.68.0.123134989791.issue11637@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
hgrepos: +33

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11637>
_______________________________________

From report at bugs.python.org  Sun Jun 19 22:20:47 2011
From: report at bugs.python.org (Michael Mulich)
Date: Sun, 19 Jun 2011 20:20:47 +0000
Subject: [issue12366] packaging.pypi.dist should abstract download errors.
In-Reply-To: <1308514847.32.0.497265184581.issue12366@psf.upfronthosting.co.za>
Message-ID: <1308514847.32.0.497265184581.issue12366@psf.upfronthosting.co.za>


New submission from Michael Mulich <michael.mulich at gmail.com>:

packaging.pypi.dist should abstract download errors, especially those from external sources. Download errors are currently reported from urllib. We should probably be using packaging.errors.PackagingPyPIError in this situation. Other suggestions?

Example case:

sake version 0.0.0 has a external download URL that throws a 404 (see also http://pypi.python.org/simple/sake/). When attempting to download this release, we receive a ValueError from urllib, which is not very detailed and could mean a number of things.

Traceback (most recent call last):
  ... [dev project] ...
  File ".../cpython/Lib/packaging/pypi/dist.py", line 167, in download
    .download(path=temp_path)
  File ".../cpython/Lib/packaging/pypi/dist.py", line 302, in download
    path + "/" + archive_name)
  File ".../cpython/Lib/urllib/request.py", line 150, in urlretrieve
    return _urlopener.retrieve(url, filename, reporthook, data)
  File ".../cpython/Lib/urllib/request.py", line 1600, in retrieve
    block = fp.read(bs)
ValueError: read of closed file

----------
assignee: tarek
components: Distutils2
messages: 138658
nosy: alexis, eric.araujo, michael.mulich, tarek
priority: normal
severity: normal
status: open
title: packaging.pypi.dist should abstract download errors.
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12366>
_______________________________________

From report at bugs.python.org  Sun Jun 19 22:22:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Jun 2011 20:22:18 +0000
Subject: [issue12367] select.error has no errno attribute
In-Reply-To: <1308514938.77.0.387292853061.issue12367@psf.upfronthosting.co.za>
Message-ID: <1308514938.77.0.387292853061.issue12367@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

It would be nice to have a errno attribute for select.error. I don't know if select.errno should inherit from OSError, WindowsError or nothing.

See also the PEP 3151:
http://www.python.org/dev/peps/pep-3151/#common-errnos-with-select-error

----------
messages: 138659
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: select.error has no errno attribute
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12367>
_______________________________________

From report at bugs.python.org  Sun Jun 19 22:24:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Jun 2011 20:24:24 +0000
Subject: [issue12366] packaging.pypi.dist should abstract download errors.
In-Reply-To: <1308514847.32.0.497265184581.issue12366@psf.upfronthosting.co.za>
Message-ID: <1308515064.25.0.182622728915.issue12366@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I agree that we can wrap exceptions to provide more useful info where needed.  It?s not necessary, however, to always catch exceptions and raise Packaging*Errors instead: distutils and packaging are documented to raise ValueError and other standard exceptions in some cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12366>
_______________________________________

From report at bugs.python.org  Sun Jun 19 22:48:41 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 19 Jun 2011 20:48:41 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <BANLkTikOz82ah-g4wz_O5q2j+h4C6=_KOQ@mail.gmail.com>
Message-ID: <480952.11691.qm@web25801.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Benjamin Peterson <benjamin at python.org> added the  comment:

> > assert(newpos != NULL)
> 
> That's because the  call is failing. Why?
> 

It's seemingly because the Python code did a seek (in Python) which was not 
communicated to the FILE object; after reading all objects from the file, a seek 
was done to the beginning to start reading again. On the previous call, the FILE 
would have been at EOF (at a C level). So it seems as if we have to call ftell 
on the Python object at the beginning of the read, and do an fseek to sync the 
positions. It's doable, of course, so it's the next thing I'll try, but what I'm 
worried about is the thing turning into a bit of a rabbit-hole.

I haven't looked at the io implementation, but for this sort of synchronisation, 
it would be better if when based on a FILE object, the io implementation 
delegated all its operations to the FILE object - but it doesn't look like 
that's the case, and I'm uncomfortable that there may be some undesirable 
consequences of that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sun Jun 19 22:57:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 19 Jun 2011 20:57:12 +0000
Subject: [issue12261] urllib.parse docs still refer to urlparse
In-Reply-To: <1307129696.46.0.265723026729.issue12261@psf.upfronthosting.co.za>
Message-ID: <E1QYP3P-0001X3-2x@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 4211ace1ff5d by Senthil Kumaran in branch '3.1':
Fix closes issue12261 - Minor documention changes in the urllib.parse.rst
http://hg.python.org/cpython/rev/4211ace1ff5d

New changeset 18f3239b3d48 by Senthil Kumaran in branch '3.2':
merge from 3.1 for issue issue12261.
http://hg.python.org/cpython/rev/18f3239b3d48

----------
nosy: +python-dev
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12261>
_______________________________________

From report at bugs.python.org  Sun Jun 19 23:08:20 2011
From: report at bugs.python.org (Michael Mulich)
Date: Sun, 19 Jun 2011 21:08:20 +0000
Subject: [issue12368] packaging.pypi.simple.Crawler assumes external download
	links are ok to follow
In-Reply-To: <1308517699.95.0.568809306044.issue12368@psf.upfronthosting.co.za>
Message-ID: <1308517699.95.0.568809306044.issue12368@psf.upfronthosting.co.za>


New submission from Michael Mulich <michael.mulich at gmail.com>:

The packaging.pypi.simple.Crawler blindly follows external download URLs. The crawler should honor a list of allowed hosts (see also the hosts parameter) before attempting to download from an external source.

?ric Araujo has also pointed out that established tools like easy_install and pip provide ways of allowing/restricting by host.

----------
assignee: tarek
components: Distutils2
messages: 138663
nosy: alexis, eric.araujo, michael.mulich, tarek
priority: normal
severity: normal
status: open
title: packaging.pypi.simple.Crawler assumes external download links are ok to follow
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12368>
_______________________________________

From report at bugs.python.org  Sun Jun 19 23:08:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Jun 2011 21:08:52 +0000
Subject: [issue12363] test_signal.test_without_siginterrupt() sporadic
	failures on FreeBSD 6.4
In-Reply-To: <1308504105.8.0.100099791428.issue12363@psf.upfronthosting.co.za>
Message-ID: <1308517732.02.0.248465302216.issue12363@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tried to patch the test to use a semaphore, but my patch was not reliable (don't remove completly the race condition).

Here is a patch using a subprocess to:
 - have only one thread
 - have a timeout on the blocking read (select cannot be used in the test, select always fail with EINTR, the kernel doesn't restart it)
 - not touch signal handling of the parent process

It is also based on time: it uses alarm() to raise a signal in one second, and use an hardcoded timeout of 3 seconds. But it doesn't need tricky synchronization between two processes.

----------
keywords: +patch
nosy: +pitrou
Added file: http://bugs.python.org/file22409/test_siginterrupt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12363>
_______________________________________

From report at bugs.python.org  Sun Jun 19 23:10:22 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 19 Jun 2011 21:10:22 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1308517822.49.0.989383264119.issue12291@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

@Benjamin: I missed commenting on your "Why not 0?", but here's the reasoning: one can't assume that the file only contains one object to be read, at the beginning of the file. It may be that some data is being written to file using marshal.dump, interspersed with other data, and then the stream is being read in at a later time, with marshal.load called to load a previously saved object. In that scenario, why would 0 be always the correct offset value to pass to fseek?

I am synchronising the Python object with the FILE *, but not the other way around - in the failing case I mentioned, external Python code has positioned the io object to zero, but that of course will be overwritten to point the io object back to where the FILE object is positioned. Perhaps I just need to go the other way ...

I'm not sure how reliable a solution will be which tries to work around there apparently being two buffering implementations - at the io level and at the FILE level, and trying to keep them synced in a seemingly ad hoc fashion.

It's perfectly possible that I don't know what I'm talking about, so I'd welcome an improved patch using the ideas you've suggested. It's been a very long time since I wrote C stdio code regularly ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sun Jun 19 23:12:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Jun 2011 21:12:20 +0000
Subject: [issue12368] packaging.pypi.simple.Crawler assumes external download
	links are ok to follow
In-Reply-To: <1308517699.95.0.568809306044.issue12368@psf.upfronthosting.co.za>
Message-ID: <1308517940.22.0.541215819689.issue12368@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Extract from IRC:
<pumazi> hmm... I'm thinking Crawler's follow_externals flag isn't working as expected
[...]
<pumazi> I'm not sure, my assumption of [its] function could be off
[...]
<merwok> ?hosts is a list of hosts allowed to be processed if follow_externals is true (default behavior is to follow all hosts), follow_externals enables or disables following external links (default is false, meaning disabled).?
<pumazi> Well, I was assuming it would disable external downloads
<merwok> I think ?external links? are external links to be scraped, not download links
<merwok> But I see your misunderstanding
<pumazi> I see, but wouldn't we want the same restrictions on download links?
[...]
<merwok> IIUC, follow_externals can be disabled because it?s guesswork
<merwok> The info obtained from XML-RPC or the simple interface is not guesswork
<merwok> So I think you could want to disable guessing from external links, but I don?t see why you should care about the origin of the download
<pumazi> trust issues I suppose
<merwok> But the same person can upload a malicious file to PyPI as well as on their site
<merwok> Without reading the code, I think this is the rationale.  OTOH, if easy_install and pip can restrict downloads and your user expectations show that it can be needed to restrict downloads, let?s file a bug

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12368>
_______________________________________

From report at bugs.python.org  Sun Jun 19 23:37:58 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 19 Jun 2011 21:37:58 +0000
Subject: [issue12255] A few changes to .*ignore
In-Reply-To: <1307119345.93.0.971452096543.issue12255@psf.upfronthosting.co.za>
Message-ID: <1308519478.87.0.597095163302.issue12255@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I strictly have not faced any problem with those rej and orig files being present in the .hgignore. I also thought keeping the .hgignore in the repo was for distribution and never knew that it can affect local views (If you remove .rej and .orig your local version, will it help?)

Yes, mercurial presents us with a list of files are that being added/committed, so we can be careful in not add those spurious leftovers. But at a time when you want to be fast with doing everything via cli options you are at a risk of adding unwanted files (unless protected by .hgignore file).

I see that .hgignore can ignore itself. So, once commited with itself to ignore, I believe people can have personal customization in there. This suggestion is with the understanding that repo/.hgignore is just to distribution and does not affect hg tracking behavior. Please correct me if I am wrong here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12255>
_______________________________________

From report at bugs.python.org  Mon Jun 20 00:03:38 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Sun, 19 Jun 2011 22:03:38 +0000
Subject: [issue12369] Revised core mentorship section of help.rst
In-Reply-To: <1308521018.32.0.427730069007.issue12369@psf.upfronthosting.co.za>
Message-ID: <1308521018.32.0.427730069007.issue12369@psf.upfronthosting.co.za>


New submission from Adam Woodbeck <adam.woodbeck at gmail.com>:

Here is the latest update to the devguide's help.rst for your consideration.  It includes Nick's tweaks to what I originally submitted.

----------
components: Devguide
files: help.rst.patch
keywords: patch
messages: 138668
nosy: adam.woodbeck, ncoghlan
priority: normal
severity: normal
status: open
title: Revised core mentorship section of help.rst
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file22410/help.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12369>
_______________________________________

From report at bugs.python.org  Mon Jun 20 00:10:17 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 19 Jun 2011 22:10:17 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1308521417.57.0.56329397885.issue12291@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think you're right about playing with the bare fd being too fragile. I think a simpler solution is to read say 1024 bytes at a time and buffer it internally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Mon Jun 20 00:28:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Jun 2011 22:28:11 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1308522491.81.0.440937128115.issue3067@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/issue3067>
_______________________________________

From report at bugs.python.org  Mon Jun 20 00:28:30 2011
From: report at bugs.python.org (Michael Foord)
Date: Sun, 19 Jun 2011 22:28:30 +0000
Subject: [issue12370] Use of super overwrites use of __class__ in class
	namespace
In-Reply-To: <1308522510.81.0.637011547356.issue12370@psf.upfronthosting.co.za>
Message-ID: <1308522510.81.0.637011547356.issue12370@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

In Python 3 the following code prints "False" because the use of super() has caused the __class__ descriptor to be omitted from the class namespace. Remove the use of super and it prints "True".


class X(object):
    
    def __init__(self):
        super().__init__()
    
    @property
    def __class__(self):
        return int
        
print (isinstance(X(), int))

----------
messages: 138670
nosy: michael.foord
priority: normal
severity: normal
status: open
title: Use of super overwrites use of __class__ in class namespace
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12370>
_______________________________________

From report at bugs.python.org  Mon Jun 20 00:28:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Jun 2011 22:28:47 +0000
Subject: [issue9436] test_sysconfig failure: build a 32-bit Python a 64-bit OS
In-Reply-To: <1280591591.84.0.476083865565.issue9436@psf.upfronthosting.co.za>
Message-ID: <1308522527.31.0.94808459292.issue9436@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: test_sysconfig failure -> test_sysconfig failure: build a 32-bit Python a 64-bit OS

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9436>
_______________________________________

From report at bugs.python.org  Mon Jun 20 00:40:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Jun 2011 22:40:24 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1308523224.19.0.0885816822806.issue7652@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/issue7652>
_______________________________________

From report at bugs.python.org  Mon Jun 20 00:48:29 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 19 Jun 2011 22:48:29 +0000
Subject: [issue12370] Use of super overwrites use of __class__ in class
	namespace
In-Reply-To: <1308522510.81.0.637011547356.issue12370@psf.upfronthosting.co.za>
Message-ID: <1308523709.22.0.421092987646.issue12370@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/issue12370>
_______________________________________

From report at bugs.python.org  Mon Jun 20 00:57:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Jun 2011 22:57:15 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1308524235.63.0.345095182484.issue12191@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

shutil_chown-default-v3.patch:
 - os.chown() is only available on Unix, shutil.chown() should not be defined if os.chown() doesn't exist (require to add a @unittest.skipUnless decorator to the test)
 - tests: is it possible that shutil.chown() exists whereas pwd or grp module is missing? if yes, you should split the test into two parts. it looks like pwd and grp are avaiable on Unix.
 - os.chown(path, -1, -1) is accepted, why not accepting shutil.chown(path) (shutil.chown(path, None, None))?
 - style: i don't like _user name, i suggest uid and gid (or user_id and group_id) instead of _user and _group... or you can reuse user/group variables
 - style: "else: \n if not isinstance(user, int):" can be written "elif not isinstance(user, int):" to avoid an useless level of indentation
 - tests: you may only call os.getuid() and os.getgid() once

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Mon Jun 20 01:04:53 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 19 Jun 2011 23:04:53 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1308521417.57.0.56329397885.issue12291@psf.upfronthosting.co.za>
Message-ID: <27487.70654.qm@web25805.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Benjamin Peterson <benjamin at python.org> added the  comment:
> 
> I think you're right about playing with the bare fd being too  fragile. I think 
>a simpler solution is to read say 1024 bytes at a time and  buffer it  
>internally.

Doesn't this suffer from a similar problem? Namely, external Python code 
expecting the stream pointer to always be just past the object just read. See my 
earlier comments pointing out that there's nowhere to store the buffer state 
between successive calls to marshal.load. And the synchronising can be a problem 
to achieve with non-seekable streams (including, but not limited to, sockets).

I'm not trying to be difficult. No, really! :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Mon Jun 20 01:15:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Jun 2011 23:15:26 +0000
Subject: [issue12314] regrtest checks (os.environ, sys.path,
	etc.) are hard to use
In-Reply-To: <1307722749.85.0.48203387339.issue12314@psf.upfronthosting.co.za>
Message-ID: <1308525326.7.0.281115181287.issue12314@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I?d like regrtest to tell me what exactly was changed, and where.

regrtests has many tests (you give some examples: os.environ, sys.path), run all tests after calling a single test function would make regrtest slower. We can add an option (e.g. --strict?) to run these sanity tests after calling a single test function.

I would also be nice to have this option for the refleak checks: run refleak checks on each function, instead of doing the checks on the whole file.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12314>
_______________________________________

From report at bugs.python.org  Mon Jun 20 01:17:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Jun 2011 23:17:56 +0000
Subject: [issue12338] multiprocessing.util._eintr_retry doen't recalculate
	timeouts
In-Reply-To: <1308144268.86.0.218604754177.issue12338@psf.upfronthosting.co.za>
Message-ID: <1308525476.6.0.782241890223.issue12338@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12338>
_______________________________________

From report at bugs.python.org  Mon Jun 20 01:29:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Jun 2011 23:29:44 +0000
Subject: [issue12338] multiprocessing.util._eintr_retry doen't recalculate
	timeouts
In-Reply-To: <1308144268.86.0.218604754177.issue12338@psf.upfronthosting.co.za>
Message-ID: <1308526184.93.0.752288852931.issue12338@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

subprocess._communicate_with_select() retries select.select() on EINTR: it recomputes timeout before each call.

while self._read_set or self._write_set:
    timeout = self._remaining_time(endtime)
    if timeout is not None and timeout < 0:
        raise TimeoutExpired(self.args, orig_timeout)
    try:
        (rlist, wlist, xlist) = \
            select.select(self._read_set, self._write_set, [],
                          timeout)
    except select.error as e:
        if e.args[0] == errno.EINTR:
            continue
        raise
    ...

It has a similar code for select.poll().

asyncore.poll() handles EINTR: it just returns.

> I think it would be better to just implement the retrying version
> of select directly.

It would be nice to share more code between subprocess and multiprocessing, but I don't know where such code should be moved. Create a new module just for one function is stupid. Handling EINTR is a common problem when managing subprocesses.

subprocess has a _eintr_retry_call() function.

multiprocessing has a @_eintr_retry decorator handling supporting more error types (use except (EnvironmentError, select.error):).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12338>
_______________________________________

From report at bugs.python.org  Mon Jun 20 02:00:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jun 2011 00:00:45 +0000
Subject: [issue12315] Improve http.client.HTTPResponse.read documentation
In-Reply-To: <1307733776.17.0.904388798994.issue12315@psf.upfronthosting.co.za>
Message-ID: <E1QYRv1-0004Hs-Uk@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d801b570b1dd by Senthil Kumaran in branch '3.2':
Fix closes Issue12315 - Updates to http.client documentation.
http://hg.python.org/cpython/rev/d801b570b1dd

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12315>
_______________________________________

From report at bugs.python.org  Mon Jun 20 02:42:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jun 2011 00:42:35 +0000
Subject: [issue12359] tutorial: Module search path description is incorrect
In-Reply-To: <1308407695.09.0.303681719961.issue12359@psf.upfronthosting.co.za>
Message-ID: <E1QYSZW-0006bh-Dv@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bf8b4c43fb94 by Senthil Kumaran in branch '3.2':
Fix closes Issue12359 - Minor update to module import description.
http://hg.python.org/cpython/rev/bf8b4c43fb94

New changeset 8754fd2ff64a by Senthil Kumaran in branch 'default':
merge from 3.2. Issue 12359
http://hg.python.org/cpython/rev/8754fd2ff64a

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12359>
_______________________________________

From report at bugs.python.org  Mon Jun 20 02:45:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jun 2011 00:45:02 +0000
Subject: [issue12370] Use of super overwrites use of __class__ in class
	namespace
In-Reply-To: <1308522510.81.0.637011547356.issue12370@psf.upfronthosting.co.za>
Message-ID: <E1QYSbt-0006kU-Es@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2d62ee4e7d98 by Benjamin Peterson in branch 'default':
use a invalid name for the __class__ closure for super() (closes #12370)
http://hg.python.org/cpython/rev/2d62ee4e7d98

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12370>
_______________________________________

From report at bugs.python.org  Mon Jun 20 02:46:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jun 2011 00:46:21 +0000
Subject: [issue12359] tutorial: Module search path description is incorrect
In-Reply-To: <1308407695.09.0.303681719961.issue12359@psf.upfronthosting.co.za>
Message-ID: <E1QYSdA-0006vO-JO@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6c16a31e0442 by Senthil Kumaran in branch '2.7':
Fix issue12359. Minor doc update on import module description.
http://hg.python.org/cpython/rev/6c16a31e0442

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12359>
_______________________________________

From report at bugs.python.org  Mon Jun 20 03:25:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jun 2011 01:25:40 +0000
Subject: [issue12360] Doc Typo
In-Reply-To: <1308427873.33.0.846212256461.issue12360@psf.upfronthosting.co.za>
Message-ID: <E1QYTFC-0000ms-No@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d310cc1c3a5d by Senthil Kumaran in branch '3.2':
Fix closes issue 12360 -  correcting parameter names in asyncore documentation.
http://hg.python.org/cpython/rev/d310cc1c3a5d

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12360>
_______________________________________

From report at bugs.python.org  Mon Jun 20 03:25:53 2011
From: report at bugs.python.org (Jeff McNeil)
Date: Mon, 20 Jun 2011 01:25:53 +0000
Subject: [issue12365] URLopener should support context manager protocol
In-Reply-To: <1308504365.98.0.668285563314.issue12365@psf.upfronthosting.co.za>
Message-ID: <1308533153.23.0.206940910369.issue12365@psf.upfronthosting.co.za>


Jeff McNeil <jeff at jmcneil.net> added the comment:

In looking at this again, I may have spoken too soon. It seems that addinfobase & HTTPResponse already handle this. As this is what's returned by the opener, then what I was shooting for should already be handled.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12365>
_______________________________________

From report at bugs.python.org  Mon Jun 20 03:27:34 2011
From: report at bugs.python.org (Dave Abrahams)
Date: Mon, 20 Jun 2011 01:27:34 +0000
Subject: [issue11376] Solaris/GCC/shared lib problem
In-Reply-To: <1299082769.75.0.912514538655.issue11376@psf.upfronthosting.co.za>
Message-ID: <1308533254.92.0.612942425771.issue11376@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

I run:

 sudo pip install --upgrade twisted

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11376>
_______________________________________

From report at bugs.python.org  Mon Jun 20 03:33:37 2011
From: report at bugs.python.org (Dave Abrahams)
Date: Mon, 20 Jun 2011 01:33:37 +0000
Subject: [issue11376] Solaris/GCC/shared lib problem
In-Reply-To: <1299082769.75.0.912514538655.issue11376@psf.upfronthosting.co.za>
Message-ID: <1308533617.7.0.943715150969.issue11376@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

Note: even after I install Sun CC, -KPIC is unrecognized.  At least it's only a warning in this case:

$ sudo pip install --upgrade twisted
Downloading/unpacking twisted
  Running setup.py egg_info for package twisted
Downloading/unpacking zope.interface (from twisted)
  Running setup.py egg_info for package zope.interface
Downloading/unpacking setuptools (from zope.interface->twisted)
  Running setup.py egg_info for package setuptools
Installing collected packages: setuptools, twisted, zope.interface
  Found existing installation: setuptools 0.6c12dev-r88846
    Uninstalling setuptools:
      Successfully uninstalled setuptools
  Running setup.py install for setuptools
    Installing easy_install script to /usr/bin
    Installing easy_install-2.6 script to /usr/bin
  Found existing installation: Twisted 10.0.0
    Uninstalling Twisted:
      Successfully uninstalled Twisted
  Running setup.py install for twisted
    /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c conftest.c -o conftest.o
    cc: unrecognized option `-KPIC'
    /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c conftest.c -o conftest.o
    cc: unrecognized option `-KPIC'
    conftest.c:1:23: sys/epoll.h: No such file or directory
    building 'twisted.runner.portmap' extension
    /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c twisted/runner/portmap.c -o build/temp.solaris-2.11-i86pc-2.6/twisted/runner/portmap.o
    cc: unrecognized option `-KPIC'
    /usr/lib/python2.6/pycc -G build/temp.solaris-2.11-i86pc-2.6/twisted/runner/portmap.o -L/usr/lib -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/twisted/runner/portmap.so
    building 'twisted.test.raiser' extension
    /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c twisted/test/raiser.c -o build/temp.solaris-2.11-i86pc-2.6/twisted/test/raiser.o
    cc: unrecognized option `-KPIC'
    /usr/lib/python2.6/pycc -G build/temp.solaris-2.11-i86pc-2.6/twisted/test/raiser.o -L/usr/lib -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/twisted/test/raiser.so
    building 'twisted.python._initgroups' extension
    /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c twisted/python/_initgroups.c -o build/temp.solaris-2.11-i86pc-2.6/twisted/python/_initgroups.o
    cc: unrecognized option `-KPIC'
    /usr/lib/python2.6/pycc -G build/temp.solaris-2.11-i86pc-2.6/twisted/python/_initgroups.o -L/usr/lib -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/twisted/python/_initgroups.so
    building 'twisted.internet._sigchld' extension
    /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c twisted/internet/_sigchld.c -o build/temp.solaris-2.11-i86pc-2.6/twisted/internet/_sigchld.o
    cc: unrecognized option `-KPIC'
    In file included from /usr/include/python2.6/Python.h:8,
                     from twisted/internet/_sigchld.c:9:
    /usr/include/python2.6/pyconfig.h:1004:1: warning: "_FILE_OFFSET_BITS" redefined
    In file included from /usr/include/signal.h:36,
                     from twisted/internet/_sigchld.c:6:
    /usr/include/sys/feature_tests.h:209:1: warning: this is the location of the previous definition
    /usr/lib/python2.6/pycc -G build/temp.solaris-2.11-i86pc-2.6/twisted/internet/_sigchld.o -L/usr/lib -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/twisted/internet/_sigchld.so
    changing mode of build/scripts-2.6/manhole from 644 to 755
    changing mode of build/scripts-2.6/mktap from 644 to 755
    changing mode of build/scripts-2.6/pyhtmlizer from 644 to 755
    changing mode of build/scripts-2.6/twistd from 644 to 755
    changing mode of build/scripts-2.6/trial from 644 to 755
    changing mode of build/scripts-2.6/tap2rpm from 644 to 755
    changing mode of build/scripts-2.6/tap2deb from 644 to 755
    changing mode of build/scripts-2.6/tapconvert from 644 to 755
    changing mode of build/scripts-2.6/mailmail from 644 to 755
    changing mode of build/scripts-2.6/conch from 644 to 755
    changing mode of build/scripts-2.6/cftp from 644 to 755
    changing mode of build/scripts-2.6/tkconch from 644 to 755
    changing mode of build/scripts-2.6/ckeygen from 644 to 755
    changing mode of build/scripts-2.6/lore from 644 to 755
    changing mode of /usr/bin/tap2deb to 755
    changing mode of /usr/bin/ckeygen to 755
    changing mode of /usr/bin/tap2rpm to 755
    changing mode of /usr/bin/mktap to 755
    changing mode of /usr/bin/pyhtmlizer to 755
    changing mode of /usr/bin/twistd to 755
    changing mode of /usr/bin/lore to 755
    changing mode of /usr/bin/mailmail to 755
    changing mode of /usr/bin/cftp to 755
    changing mode of /usr/bin/tkconch to 755
    changing mode of /usr/bin/conch to 755
    changing mode of /usr/bin/trial to 755
    changing mode of /usr/bin/tapconvert to 755
    changing mode of /usr/bin/manhole to 755
  Found existing installation: zope.interface 3.3.0
    Uninstalling zope.interface:
      Successfully uninstalled zope.interface
  Running setup.py install for zope.interface
    building 'zope.interface._zope_interface_coptimizations' extension
    /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c src/zope/interface/_zope_interface_coptimizations.c -o build/temp.solaris-2.11-i86pc-2.6/src/zope/interface/_zope_interface_coptimizations.o
    cc: unrecognized option `-KPIC'
    /usr/lib/python2.6/pycc -G build/temp.solaris-2.11-i86pc-2.6/src/zope/interface/_zope_interface_coptimizations.o -L/usr/lib -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/zope/interface/_zope_interface_coptimizations.so
    Skipping installation of /usr/lib/python2.6/site-packages/zope/__init__.py (namespace package)
    Installing /usr/lib/python2.6/site-packages/zope.interface-3.6.3-py2.6-nspkg.pth
Successfully installed setuptools twisted zope.interface
Cleaning up...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11376>
_______________________________________

From report at bugs.python.org  Mon Jun 20 04:34:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jun 2011 02:34:25 +0000
Subject: [issue12255] A few changes to .*ignore
In-Reply-To: <1307119345.93.0.971452096543.issue12255@psf.upfronthosting.co.za>
Message-ID: <1308537265.04.0.616400048311.issue12255@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I have no idea what you mean by "for distrabution" in this context.  The .hgignore in the checkout causes hg to ignore the files/patterns listed in it when any hg commands are run against that checkout.  And no I can't remove it in my "local copy", since the whole point of the file is that is is under version control in the repo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12255>
_______________________________________

From report at bugs.python.org  Mon Jun 20 05:01:48 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 20 Jun 2011 03:01:48 +0000
Subject: [issue12255] A few changes to .*ignore
In-Reply-To: <1308537265.04.0.616400048311.issue12255@psf.upfronthosting.co.za>
Message-ID: <20110620030143.GA7524@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

By "for distribution", I meant that everyone who checks out ( clones)
from hg.cpython.org repository share the same .hgignore file, instead
of each person having to create their own file. 

I got an impression from the earlier message that hg tracks (or
ignores tracking) based on .hgignore file in the server itself, which
I wanted to clarify.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12255>
_______________________________________

From report at bugs.python.org  Mon Jun 20 05:03:26 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jun 2011 03:03:26 +0000
Subject: [issue6734] Imap lib implicit conversion from bytes to string
In-Reply-To: <1250687880.61.0.0161540410601.issue6734@psf.upfronthosting.co.za>
Message-ID: <1308539006.59.0.892248267342.issue6734@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This was fixed in issue 4471 by Antoine when he added some tests that call login.  He fixed it by changing _quote to work with strings.  Per the discussion here I'm not sure this is the best fix, but until someone reports a bug with it it we may as well let it stand.

----------
nosy: +pitrou
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> IMAP4 missing support for starttls

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6734>
_______________________________________

From report at bugs.python.org  Mon Jun 20 05:10:05 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jun 2011 03:10:05 +0000
Subject: [issue12255] A few changes to .*ignore
In-Reply-To: <1307119345.93.0.971452096543.issue12255@psf.upfronthosting.co.za>
Message-ID: <1308539405.25.0.235503454169.issue12255@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, since there's no central server for hg, it can't track based on the server.  Perhaps I confused you by saying that the .hgignore file was "in the repo".  (It is "in the repo" in the sense that any tracked file is in the repo, but it's effect comes from its existence in the checkout tree from which you are running the hg commands.)

So yes, the .hgignore you get when you clone is so that everybody has the same base list.  That's why we are arguing about its appropriate contents :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12255>
_______________________________________

From report at bugs.python.org  Mon Jun 20 05:19:02 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jun 2011 03:19:02 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1308539942.84.0.366219017031.issue12291@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/issue12291>
_______________________________________

From report at bugs.python.org  Mon Jun 20 06:06:12 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 20 Jun 2011 04:06:12 +0000
Subject: [issue12255] A few changes to .*ignore
In-Reply-To: <1307119345.93.0.971452096543.issue12255@psf.upfronthosting.co.za>
Message-ID: <1308542772.97.0.451032215415.issue12255@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I tried to a line .hgignore inside .hgignore file, so that it can ignore itself (weird concept, but wanted to try if it works) and users can make local customization of it without any problem. This has been suggest at many places in the Internet.  I tried by completing removing the file and adding a new one with .hgignore ignoring itself. But it does'nt seem to work. 

So a possible solution seems like this: If .rej and .orig needs to be removed from .hgignore, one should just remove it from the .hgignore file and for people who do not want to be bothered by .rej/.orig files in hg st, they can create an addition ignore directive in their .hgrc
http://mercurial.selenic.com/wiki/TipsAndTricks#Ignore_files_in_local_working_copy_only

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12255>
_______________________________________

From report at bugs.python.org  Mon Jun 20 07:07:42 2011
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Mon, 20 Jun 2011 05:07:42 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1308546462.71.0.411271426176.issue4470@psf.upfronthosting.co.za>


Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it> added the comment:

I'd still prefer if smtplib_05_shutdown_socket_v2.patch could get in,
                                                       ^^^^^^^^^^^^^^
since, this way the REMOTE socket close will be unconditionally correct,
instead of being dependent on GC artifacts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Mon Jun 20 08:57:27 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 20 Jun 2011 06:57:27 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1308553047.05.0.859923543554.issue12291@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


Added file: http://bugs.python.org/file22411/9e367c8fd949.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Mon Jun 20 08:58:15 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 20 Jun 2011 06:58:15 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1308553095.61.0.0193303940161.issue12291@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


Removed file: http://bugs.python.org/file22290/marshal-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Mon Jun 20 08:58:27 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 20 Jun 2011 06:58:27 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1308553107.75.0.217551100767.issue12291@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


Removed file: http://bugs.python.org/file22314/marshal-patch2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Mon Jun 20 09:41:58 2011
From: report at bugs.python.org (olrait)
Date: Mon, 20 Jun 2011 07:41:58 +0000
Subject: [issue12371] datetime.now() bug
In-Reply-To: <BANLkTimYvovSOakbD_hdZUzt=V_xD=vNMg@mail.gmail.com>
Message-ID: <BANLkTimYvovSOakbD_hdZUzt=V_xD=vNMg@mail.gmail.com>


New submission from olrait <martinmaqueira at gmail.com>:

Hello Everybody.

I write you because I found a bug in datetime.now(). (tested in Python 2.6.6
-r266:84297, Aug 24 2010, 18:46:32-win32) This bug is that sometime doesn??t
return milliseconds.

The code to reproduce the bug is: you have to wait a lot of time (from 20
minutes to 2 hours)

from datetime import datetime

while True:

            a=str(datetime.now())

            try:

                        b=a.split(".")[1]

                        print b

            except:

                        print "exception a=%s (if you see in this case there
are not the milliseconds) " % (str(a))

                        break

I new in this . Programing and python specially.

Best Regards

Martin Maqueira

----------
files: unnamed
messages: 138689
nosy: olrait
priority: normal
severity: normal
status: open
title: datetime.now() bug
Added file: http://bugs.python.org/file22412/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12371>
_______________________________________
-------------- next part --------------
<p class="MsoNormal"><font face="Times New Roman" size="3"><span style="FONT-SIZE: 12pt">??</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hello 
Everybody.</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">??</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">I write you because I found a bug in 
datetime.now(). (tested in Python 2.6.6 -r266:84297, Aug 24 2010, 
18:46:32-win32) This bug is that sometime doesn??t return 
milliseconds.</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">??</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">The code to reproduce the bug is: 
you have to wait a lot of time (from 20 minutes to 2 
hours)</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">??</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">??</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">from datetime import 
datetime</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">while 
True:</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">?????????????????????? 
a=str(datetime.now())</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">?????????????????????? 
try:</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">?????????????????????????????????????????????? 
b=a.split(&quot;.&quot;)[1]</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">?????????????????????????????????????????????? print 
b</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">?????????????????????? 
except:</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">?????????????????????????????????????????????? print 
&quot;exception a=%s (if you see in this case there are not the milliseconds) &quot; % 
(str(a))</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">?????????????????????????????????????????????? 
break</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">??</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">??</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">I new in this . Programing and 
python specially.</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">??</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Best 
Regards</span></font></p><p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><br></span></font></p><p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Martin Maqueira</span></font></p>

<p class="MsoNormal"><font face="Arial" size="2"><span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">??</span></font></p>

From report at bugs.python.org  Mon Jun 20 10:10:20 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 20 Jun 2011 08:10:20 +0000
Subject: [issue12365] URLopener should support context manager protocol
In-Reply-To: <1308504365.98.0.668285563314.issue12365@psf.upfronthosting.co.za>
Message-ID: <1308557420.03.0.87595786668.issue12365@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

well, urlopen does return an file like object for socket connection which closes itself when it goes out of scope, as you raised this bug, I think a more explicit context manager like behavior can be tried. But I am afraid that it would complex to implement with the module than it sounds.

I see some example illustrated like this:
http://stackoverflow.com/questions/1522636/should-i-call-close-after-urllib-urlopen

import contextlib

with contextlib.closing(urllib.urlopen(u)) as x:
   ...use x at will here...


But it would be good to have this ticket as a feature request open.

----------
assignee:  -> orsenthil
nosy: +orsenthil
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12365>
_______________________________________

From report at bugs.python.org  Mon Jun 20 10:13:36 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 20 Jun 2011 08:13:36 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
	"chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1308557616.36.0.199833253069.issue12319@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

We had support for chunked transfer encoding for POST method recently, which is exposed via urllib2 wrapper function. PUT is not exposed via urllib2 and users should use httplib. This feature of chunked transfer can be added to PUT by taking the body of the message as iterable.

----------
assignee:  -> orsenthil
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12319>
_______________________________________

From report at bugs.python.org  Mon Jun 20 10:36:53 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 20 Jun 2011 08:36:53 +0000
Subject: [issue12327] in HTTPConnection the are len(body) and TypeError catch
	exception to detect if body is file like object,
	this hack do work with StringIO object
In-Reply-To: <1308123776.71.0.525382200898.issue12327@psf.upfronthosting.co.za>
Message-ID: <20110620083647.GC9220@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hello Stephane,

> I use HTTPConnection to simulate Apple Finder WebDAV client.  When
> this WebDAV client do PUT request, it transmit data in chunked
> encoding mode and not set Content-Length HTTP field.
> 
> Do you understand my context ?

Is the server at fault in not returning Content-Length?

Can you provide a full working snippet which demonstrates the bug you
are facing? I fear, if I am lacking some information to completely
determine what needs to be fixed (I understand the code change you
suggested, but also need to know why and under what practical
situation would code flow through that).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12327>
_______________________________________

From report at bugs.python.org  Mon Jun 20 10:56:08 2011
From: report at bugs.python.org (reshmi george)
Date: Mon, 20 Jun 2011 08:56:08 +0000
Subject: [issue12372] semaphore errors on AIX 7.1
In-Reply-To: <1308560168.88.0.791994577012.issue12372@psf.upfronthosting.co.za>
Message-ID: <1308560168.88.0.791994577012.issue12372@psf.upfronthosting.co.za>


New submission from reshmi george <reshmi.ge at gmail.com>:

The same problem that was reported in issue 9700 is appearing on AIX 7.1. 
The following message has been seen when running multi-process python program:
sem_trywait: Permission denied
sem_post: Permission denied
sem_wait: Permission denied
sem_post: Permission denied


It can be easily corrected by defining HAVE_BROKEN_POSIX_SEMAPHORES for AIX 7, like it is done for AIX 6.

----------
messages: 138693
nosy: reshmi.george
priority: normal
severity: normal
status: open
title: semaphore errors on AIX 7.1
versions: Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12372>
_______________________________________

From report at bugs.python.org  Mon Jun 20 11:00:20 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 20 Jun 2011 09:00:20 +0000
Subject: [issue12359] tutorial: Module search path description is incorrect
In-Reply-To: <1308407695.09.0.303681719961.issue12359@psf.upfronthosting.co.za>
Message-ID: <1308560420.68.0.533077954429.issue12359@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Mon, Jun 20, 2011 at 3:42 AM, Roundup Robot <report at bugs.python.org> wrote:
>
> New changeset bf8b4c43fb94 by Senthil Kumaran in branch '3.2':
> Fix closes Issue12359 - Minor update to module import description.
> http://hg.python.org/cpython/rev/bf8b4c43fb94

1. There is a typo 'thecurrent' in this commit
2. The interpreter doesn't search current directory. The first item appended to sys.path is the directory of the importing script.

----------
resolution: fixed -> remind
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12359>
_______________________________________

From report at bugs.python.org  Mon Jun 20 11:02:57 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 20 Jun 2011 09:02:57 +0000
Subject: [issue12359] tutorial: Module search path description is incorrect
In-Reply-To: <1308407695.09.0.303681719961.issue12359@psf.upfronthosting.co.za>
Message-ID: <1308560577.83.0.213540697687.issue12359@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I attach file for testing import if anybody needs it. Move module.py to your current directory, but out of the dir with script.py and execute script.py using relative path from there.

----------
Added file: http://bugs.python.org/file22413/portable-test.7z

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12359>
_______________________________________

From report at bugs.python.org  Mon Jun 20 11:58:06 2011
From: report at bugs.python.org (Aleksey Zhurbitsky)
Date: Mon, 20 Jun 2011 09:58:06 +0000
Subject: [issue12373] Duplicate packets in Multicast Receiver
In-Reply-To: <1308563886.51.0.770044615776.issue12373@psf.upfronthosting.co.za>
Message-ID: <1308563886.51.0.770044615776.issue12373@psf.upfronthosting.co.za>


New submission from Aleksey Zhurbitsky <zhurbitsky at gmail.com>:

I use http://svn.python.org/projects/python/trunk/Demo/sockets/mcast.py to receive multicast stream. When i run one instance of this script to receive certain multicats stream all is fine, but when i run two instance of this script simultaneously to join different multicats stream whith same port - starts mess. Each script gets his packets and packets from other multicast group.
Examples of multicast groups:
rtp://224.1.1.1:1234
rtp://224.1.1.2:1234

I also try to use other code to recive multicast but got the same result - http://stackoverflow.com/questions/6387535/duplicate-packets-in-python-multicast-receiver

----------
components: Demos and Tools, Library (Lib)
messages: 138696
nosy: Aleksey Zhurbitsky
priority: normal
severity: normal
status: open
title: Duplicate packets in Multicast Receiver
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12373>
_______________________________________

From report at bugs.python.org  Mon Jun 20 12:44:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 10:44:20 +0000
Subject: [issue12371] datetime.now() bug
In-Reply-To: <BANLkTimYvovSOakbD_hdZUzt=V_xD=vNMg@mail.gmail.com>
Message-ID: <1308566660.71.0.0825924568263.issue12371@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

str(datetime object) doesn't contain a dot if obj.microsecond equals zero. You can use obj=obj.replace(microsecond=0) to create a new datetime object using microsecond=0. Or just test that str(obj) contains a dot or not.

It is not a bug in Python.

----------
nosy: +haypo
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12371>
_______________________________________

From report at bugs.python.org  Mon Jun 20 13:02:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 11:02:46 +0000
Subject: [issue12367] select.error has no errno attribute
In-Reply-To: <1308514938.77.0.387292853061.issue12367@psf.upfronthosting.co.za>
Message-ID: <1308567766.28.0.202506987485.issue12367@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

select_errno.patch: select.error now inherits from OSError and so have an errno attribute. I only ran the unit test on Linux, it should be tested on Windows.

----------
keywords: +patch
Added file: http://bugs.python.org/file22414/select_errno.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12367>
_______________________________________

From report at bugs.python.org  Mon Jun 20 13:29:45 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 20 Jun 2011 11:29:45 +0000
Subject: [issue11439] subversion keyword breakage
In-Reply-To: <1299597022.39.0.100246713924.issue11439@psf.upfronthosting.co.za>
Message-ID: <1308569385.82.0.514510836919.issue11439@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Building matplotlib with the 2.7.2 release fails due to this issue:

Traceback (most recent call last):
  File "setup.py", line 162, in <module>
    if check_for_tk() or (options['build_tkagg'] is True):
  File "/home/stefan/src/matplotlib-1.0.1/setupext.py", line 832, in check_for_tk
    (Tkinter.__version__.split()[-2], Tkinter.TkVersion, Tkinter.TclVersion))
IndexError: list index out of range


Python 2.7.2 (default, Jun 20 2011, 13:19:22) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Tkinter
>>> Tkinter.__version__
'$Revision$'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11439>
_______________________________________

From report at bugs.python.org  Mon Jun 20 13:30:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Jun 2011 11:30:17 +0000
Subject: [issue12367] select.error has no errno attribute
In-Reply-To: <1308514938.77.0.387292853061.issue12367@psf.upfronthosting.co.za>
Message-ID: <1308569417.08.0.185083686997.issue12367@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You can't do this outside of a PEP (see PEP 3151).

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12367>
_______________________________________

From report at bugs.python.org  Mon Jun 20 14:10:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 12:10:07 +0000
Subject: [issue12337] Need real TextIOWrapper for stdin/stdout
In-Reply-To: <1308113993.07.0.688068575261.issue12337@psf.upfronthosting.co.za>
Message-ID: <1308571807.26.0.392410984609.issue12337@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> so there really was a bug.
> If fixed in 3.2.1, this issue could be closed.

This issue is a duplicate of #11272: upgrade to Python 3.2.1.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12337>
_______________________________________

From report at bugs.python.org  Mon Jun 20 14:12:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 12:12:54 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1308571974.25.0.952159193617.issue11873@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> What about Windows? tempfile.mkdtemp(prefix='bar') can generate
> ...\tmpxxbaxx\... Or compileall does first normalize the path?

@r.david.murray: You reopened the issue, but you didn't answer to this question. And, is there a bug in your regex or not?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11873>
_______________________________________

From report at bugs.python.org  Mon Jun 20 14:14:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 12:14:03 +0000
Subject: [issue12090] 3.2: build --without-threads fails
In-Reply-To: <1305568611.26.0.714455176679.issue12090@psf.upfronthosting.co.za>
Message-ID: <1308572043.73.0.604102621105.issue12090@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Yes, this is fixed in 3.2.
> I just left the issue open as a reminder for the release branch.

The issue is still open, can it be closed? What do you mean by "release branch"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12090>
_______________________________________

From report at bugs.python.org  Mon Jun 20 14:26:00 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 20 Jun 2011 12:26:00 +0000
Subject: [issue12090] 3.2: build --without-threads fails
In-Reply-To: <1308572043.73.0.604102621105.issue12090@psf.upfronthosting.co.za>
Message-ID: <20110620122404.GA25282@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

STINNER Victor <report at bugs.python.org> wrote:
> > Yes, this is fixed in 3.2.
> > I just left the issue open as a reminder for the release branch.
> 
> The issue is still open, can it be closed? What do you mean by "release branch"?

This one: http://hg.python.org/releasing/3.2.1/

The issue isn't fixed there yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12090>
_______________________________________

From report at bugs.python.org  Mon Jun 20 15:01:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jun 2011 13:01:07 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <E1QYe6D-00038C-Oo@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b87eac0369b5 by Victor Stinner in branch 'default':
Issue #6697: _lsprof: normalizeUserObj() doesn't encode/decode (UTF-8) the
http://hg.python.org/cpython/rev/b87eac0369b5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Mon Jun 20 15:07:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 13:07:56 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1308575276.08.0.0248142256664.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I wrote a similar patch to add PyModule_GetNameObject() 
> (I am working on another huge patch, to fix #3080)

Issue #3080 added the PyModule_GetNameObject() function, so it simplify your patch.

I commited your issue6697-lsprof.diff patch, I just fixed a refleak (if modname is "builtins").

I want to close this generic issue. I think that we fixed enough code. If you still see code not checking that _PyUnicode_AsString() result is not NULL, please open a new specific issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Mon Jun 20 15:08:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 13:08:04 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1308575284.13.0.20259294098.issue6697@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/issue6697>
_______________________________________

From report at bugs.python.org  Mon Jun 20 15:35:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 13:35:23 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
	directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: <1308576923.44.0.57114394354.issue7732@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

import_directory-py3k.patch: find_module_path_list() ignores silently directories matching requested filename pattern (like module_name + ".py"). I don't think that it is useful to emit a warning (or raise an error) here, the code checks for various file extensions, not only .pyc: .so, .pyd, ...

----------
Added file: http://bugs.python.org/file22415/import_directory-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Mon Jun 20 15:38:08 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 20 Jun 2011 13:38:08 +0000
Subject: [issue12373] Duplicate packets in Multicast Receiver
In-Reply-To: <1308563886.51.0.770044615776.issue12373@psf.upfronthosting.co.za>
Message-ID: <1308577088.86.0.758909666119.issue12373@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

This is normal.
You're binding twice to the same port thanks to SO_REUSEADDR, but in case of multiple binds to the same UDP port, all packets received are duplicated by the kernel to every socket.
Closing as invalid.

----------
nosy: +neologix
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12373>
_______________________________________

From report at bugs.python.org  Mon Jun 20 15:40:57 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 20 Jun 2011 13:40:57 +0000
Subject: [issue12373] Duplicate packets in Multicast Receiver
In-Reply-To: <1308563886.51.0.770044615776.issue12373@psf.upfronthosting.co.za>
Message-ID: <1308577257.15.0.207221288792.issue12373@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Note that the duplication is mandatory for multicast, but with unicast the kernel is free to do whatever he wants, most of the time only one socket will receive it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12373>
_______________________________________

From report at bugs.python.org  Mon Jun 20 15:44:15 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 20 Jun 2011 13:44:15 +0000
Subject: [issue12369] Revised core mentorship section of help.rst
In-Reply-To: <1308521018.32.0.427730069007.issue12369@psf.upfronthosting.co.za>
Message-ID: <1308577455.85.0.312373485151.issue12369@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Added (with further adjustments) to devguide in http://hg.python.org/devguide/rev/63f3521fe8f8

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12369>
_______________________________________

From report at bugs.python.org  Mon Jun 20 15:44:27 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 20 Jun 2011 13:44:27 +0000
Subject: [issue12356] more argument error improving
In-Reply-To: <1308357931.79.0.860556100237.issue12356@psf.upfronthosting.co.za>
Message-ID: <1308577467.14.0.82149566734.issue12356@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12356>
_______________________________________

From report at bugs.python.org  Mon Jun 20 15:48:45 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 20 Jun 2011 13:48:45 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1308430241.85.0.832016262902.issue12326@psf.upfronthosting.co.za>
Message-ID: <BANLkTikzu1DBn_ayVMb-u6v=gJb4btShzw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> However, it appears to me that vast majority of them is broken anyway,
> because what they really mean to check is

That's exactly my point.
Code checking sys.platform against 'linux2' is already broken, there's
no point in complicating the code further, or adding a new constant.
If you want to check for a specific operating system, there's already
platform.system().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Jun 20 15:49:07 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 20 Jun 2011 13:49:07 +0000
Subject: [issue12370] Use of super overwrites use of __class__ in class
	namespace
In-Reply-To: <1308522510.81.0.637011547356.issue12370@psf.upfronthosting.co.za>
Message-ID: <1308577747.85.0.262290346485.issue12370@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

And to record the workaround for 3.1 and 3.2 (courtesy of Michael):

Adding a "_super = super" alias at the module level and using the Python 2.x style long form invocation on _super() in affected methods will avoid the compiler games played when using super() directly. That is::

_super = super
class X(object):
    
    def __init__(self):
        _super(self, X).__init__()
    
    @property
    def __class__(self):
        return int
        
print (isinstance(X(), int))

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12370>
_______________________________________

From report at bugs.python.org  Mon Jun 20 15:50:23 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 20 Jun 2011 13:50:23 +0000
Subject: [issue12370] Use of super overwrites use of __class__ in class
	namespace
In-Reply-To: <1308522510.81.0.637011547356.issue12370@psf.upfronthosting.co.za>
Message-ID: <1308577823.32.0.819527606344.issue12370@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

That work around seems ugly.  Why not back port the fix?  It doesn't seem like it could break anything and it's not even arguably a new feature, right?

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12370>
_______________________________________

From report at bugs.python.org  Mon Jun 20 15:52:20 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 20 Jun 2011 13:52:20 +0000
Subject: [issue12370] Use of super overwrites use of __class__ in class
	namespace
In-Reply-To: <1308522510.81.0.637011547356.issue12370@psf.upfronthosting.co.za>
Message-ID: <1308577940.26.0.984955209814.issue12370@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

One reason is that it bumps the pyc magic number.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12370>
_______________________________________

From report at bugs.python.org  Mon Jun 20 15:58:47 2011
From: report at bugs.python.org (vincent.chute)
Date: Mon, 20 Jun 2011 13:58:47 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1308578327.3.0.231909652568.issue3067@psf.upfronthosting.co.za>


vincent.chute <vincent.chute at onelan.co.uk> added the comment:

"Since the module predates unicode strings (it is in 1.5) and since the locale string is passed to a C function, 'string' in the doc can just as well be taken to mean ascii byte string only, as the code requires."

My only comment is that generally it doesn't seem reasonable to me that developer should need to investigate the history and implementation of a function in order to understand the documentation correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Mon Jun 20 15:59:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 13:59:11 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
	directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: <1308578351.37.0.548048742115.issue7732@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

pyfile_fromfile_close.patch: patch based on issue7732_find_module_v2.diff, fixing this issue in Python 2.7

 - PyFile_FromFile() closes the file on PyString_FromString() failure (note: unlikely failure)
 - call_find_module() doesn't close the file anymore, PyFile_FromFile() closes already the file on failure (e.g. if the path is a directory)
 - update PyFile_FromFile() doc to simplify that the file is closed on error

----------
Added file: http://bugs.python.org/file22416/pyfile_fromfile_close.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Mon Jun 20 16:00:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jun 2011 14:00:58 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1308578458.28.0.908147752112.issue11873@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I reopened the issue because I don't know the answer to your question but suspect that it is an issue.  So it needs to be checked.  And the regex should be cleaned up regardless, for clarity's sake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11873>
_______________________________________

From report at bugs.python.org  Mon Jun 20 16:09:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 14:09:30 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1308578970.86.0.823176662786.issue3067@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> On Py3, locale.setlocale() should allow only unicode strings
> and reject byte strings.

I agree and it is the current behaviour (of Python 3.3). I don't see any use case of a byte strings in locale.setlocale() with Python 3.3, so I remove Python 3 from the versions of this issue.

----------
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Mon Jun 20 16:14:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jun 2011 14:14:56 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <E1QYfFe-0001e7-Qu@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d370d609d09b by Victor Stinner in branch '2.7':
Close #3067: locale.setlocale() accepts a Unicode locale.
http://hg.python.org/cpython/rev/d370d609d09b

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Mon Jun 20 16:15:44 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 20 Jun 2011 14:15:44 +0000
Subject: [issue12370] Use of super overwrites use of __class__ in class
	namespace
In-Reply-To: <1308522510.81.0.637011547356.issue12370@psf.upfronthosting.co.za>
Message-ID: <1308579344.99.0.299032887303.issue12370@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Ah okay, I didn't see that in the changeset.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12370>
_______________________________________

From report at bugs.python.org  Mon Jun 20 16:17:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 14:17:48 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1308579468.0.0.957819558137.issue3067@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I fixed locale.setlocale() of Python 2.7 to accept Unicode string because it helps porting to Python 3...

But I think that the commit is just useless because we will have to wait until Python 2.7.3 is released, and if you want to support older Python versions, we will have to encode the locale explicitly to ASCII.

Anyway, you should move to Python 3 (3.2 or later if possible) if you want a better Unicode support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Mon Jun 20 16:19:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 14:19:28 +0000
Subject: [issue5905] strptime fails in non-UTF locale
In-Reply-To: <1241277441.59.0.031362936917.issue5905@psf.upfronthosting.co.za>
Message-ID: <1308579568.92.0.484372560844.issue5905@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I close the issue because I am unable to reproduce it.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5905>
_______________________________________

From report at bugs.python.org  Mon Jun 20 16:38:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jun 2011 14:38:24 +0000
Subject: [issue12359] tutorial: Module search path description is incorrect
In-Reply-To: <1308407695.09.0.303681719961.issue12359@psf.upfronthosting.co.za>
Message-ID: <E1QYfcN-00040H-5t@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a57134dd8688 by Senthil Kumaran in branch '3.2':
Fix closes Issue12359 - Removing a confusing sentence from the previous change.
http://hg.python.org/cpython/rev/a57134dd8688

New changeset 18ebc7809cb2 by Senthil Kumaran in branch 'default':
merge from 3.2 - Fix closes Issue12359 - Removing a confusing sentence from the previous change.
http://hg.python.org/cpython/rev/18ebc7809cb2

New changeset 51ad2d4390bc by Senthil Kumaran in branch '2.7':
merge 3.2 - Fix closes Issue12359 - Removing a confusing sentence from the previous change.
http://hg.python.org/cpython/rev/51ad2d4390bc

----------
resolution: remind -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12359>
_______________________________________

From report at bugs.python.org  Mon Jun 20 16:42:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 14:42:01 +0000
Subject: [issue4841] io's close() not handling errors correctly
In-Reply-To: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za>
Message-ID: <1308580921.18.0.983267744687.issue4841@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

fileio_close.patch (for Python 3.3): Fix FileIO.__init__() to not close the file if closefd=False and the constructor is called twice (or more).

----------
Added file: http://bugs.python.org/file22417/fileio_close.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4841>
_______________________________________

From report at bugs.python.org  Mon Jun 20 16:44:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 14:44:20 +0000
Subject: [issue4841] io's close() not handling errors correctly
In-Reply-To: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za>
Message-ID: <1308581060.4.0.26004783237.issue4841@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

fileio_close.patch should maybe use os.open() (to create the fd) and os.fstat() (to check that the fd is not closed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4841>
_______________________________________

From report at bugs.python.org  Mon Jun 20 17:03:08 2011
From: report at bugs.python.org (Jeff McNeil)
Date: Mon, 20 Jun 2011 15:03:08 +0000
Subject: [issue12365] URLopener should support context manager protocol
In-Reply-To: <1308504365.98.0.668285563314.issue12365@psf.upfronthosting.co.za>
Message-ID: <1308582188.61.0.342800033159.issue12365@psf.upfronthosting.co.za>


Jeff McNeil <jeff at jmcneil.net> added the comment:

Isn't that snippet (contextlib.closing(...)) passing the result of urllib.urlopen to closing? The urlopen call is a factory function of sorts, so there's really no context to manage on its part?  Maybe it's just a matter of making that clear?

If you can share what you've got in mind, I'd love to give it a go. The urllib stuff I've done thus far has been a great way to get my feet wet!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12365>
_______________________________________

From report at bugs.python.org  Mon Jun 20 17:12:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 15:12:41 +0000
Subject: [issue4841] io's close() not handling errors correctly
In-Reply-To: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za>
Message-ID: <1308582761.67.0.662199059052.issue4841@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Status of this issue:
 - io.FileIO.close() raises IOError with Python 2.7, 3.1, 3.2 and 3.3 (e.g. if the underlying file descriptor has been closed), it doesn't with Python 2.6
 - If FileIO constructor is called twice, the file is closed at the second call even if closefd was False at the first call: bug in Python 2.6-3.3: fileio_close.patch fixes this bug

So except fixing FileIO constructor (using fileio_close.patch) in Python 2.7, 3.2 and 3.3, there is nothing more to do.

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4841>
_______________________________________

From report at bugs.python.org  Mon Jun 20 17:15:11 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 20 Jun 2011 15:15:11 +0000
Subject: [issue12374] Execution model should explain compile vs definition vs
	execution time
In-Reply-To: <1308582911.55.0.701954968644.issue12374@psf.upfronthosting.co.za>
Message-ID: <1308582911.55.0.701954968644.issue12374@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The current execution model documentation in the Language Reference doesn't clearly explain the multiple phases of code execution:

1. Compilation time (statement by statement in the main module and at the interactive prompt, all at once for module import and the exec() and compile() builtins)
2. Definition time for function statements (i.e. when the function statement itself is executed)
3. Execution time for function and generator bodies (i.e. when a function is called and when next() is invoked on a generator)

----------
messages: 138728
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Execution model should explain compile vs definition vs execution time

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12374>
_______________________________________

From report at bugs.python.org  Mon Jun 20 17:18:50 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 20 Jun 2011 15:18:50 +0000
Subject: [issue12090] 3.2: build --without-threads fails
In-Reply-To: <1305568611.26.0.714455176679.issue12090@psf.upfronthosting.co.za>
Message-ID: <1308583130.12.0.212055261048.issue12090@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It doesn't need to; this branch is inactive at the moment.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12090>
_______________________________________

From report at bugs.python.org  Mon Jun 20 17:22:25 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 20 Jun 2011 15:22:25 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1308583345.84.0.39287057122.issue12326@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> That's exactly my point.
> Code checking sys.platform against 'linux2' is already broken, there's
> no point in complicating the code further, or adding a new constant.
> If you want to check for a specific operating system, there's already
> platform.system().

I would agree with this. Perhaps the documentation for sys.platform could be changed to mention that platform.system() should maybe be used instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Jun 20 17:26:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 15:26:19 +0000
Subject: [issue10086] test_sysconfig failure when prefix matches /site
In-Reply-To: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>
Message-ID: <1308583579.62.0.906342412673.issue10086@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/issue10086>
_______________________________________

From report at bugs.python.org  Mon Jun 20 17:27:20 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 20 Jun 2011 15:27:20 +0000
Subject: [issue12289] http.server.CGIHTTPRequestHandler doesn't check if a
	Python script is executable
In-Reply-To: <1307576847.86.0.0933852341785.issue12289@psf.upfronthosting.co.za>
Message-ID: <1308583640.33.0.346163102848.issue12289@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Both the changes suggested in the patch are fine. I think, it is okay to remove the executable function. It is undocumented as it is, and have not seen any standalone use of it. A note in NEWS can help.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12289>
_______________________________________

From report at bugs.python.org  Mon Jun 20 17:32:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Jun 2011 15:32:32 +0000
Subject: [issue6584] gzip module has no custom exception
In-Reply-To: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>
Message-ID: <1308583952.67.0.574770921805.issue6584@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ezio has found a few other things to improve (follow the ?review? link to the right of the patch link).

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6584>
_______________________________________

From report at bugs.python.org  Mon Jun 20 17:42:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jun 2011 15:42:16 +0000
Subject: [issue12374] Execution model should explain compile vs definition vs
	execution time
In-Reply-To: <1308582911.55.0.701954968644.issue12374@psf.upfronthosting.co.za>
Message-ID: <1308584536.79.0.513309008319.issue12374@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Isn't 'definition time' vs 'execution time' an artificial distinction?  I'm surprised that the main module is compiled differently than a regular module.  Is that an artifact of the CPython implementation or a part of the language?  If the latter it should certainly be documented. 

What are the concrete differences between 'execution time' and 'defintion time' that are missing from the language specification?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12374>
_______________________________________

From report at bugs.python.org  Mon Jun 20 17:47:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jun 2011 15:47:01 +0000
Subject: [issue12289] http.server.CGIHTTPRequestHandler doesn't check if a
	Python script is executable
In-Reply-To: <1307576847.86.0.0933852341785.issue12289@psf.upfronthosting.co.za>
Message-ID: <E1QYggl-0002Jw-Qy@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ecef74419d55 by Victor Stinner in branch 'default':
Close #12289: Fix "is executable?" test in the CGI server
http://hg.python.org/cpython/rev/ecef74419d55

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12289>
_______________________________________

From report at bugs.python.org  Mon Jun 20 17:55:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jun 2011 15:55:43 +0000
Subject: [issue12285] Unexpected behavior for 0 or negative processes in
	multiprocessing.pool()
In-Reply-To: <1307541329.07.0.743246465318.issue12285@psf.upfronthosting.co.za>
Message-ID: <E1QYgpB-00038J-PX@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1f171dd21bdb by Victor Stinner in branch '3.2':
Issue #12285: multiprocessing.Pool() raises a ValueError if the number of
http://hg.python.org/cpython/rev/1f171dd21bdb

New changeset 1861683793d9 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12285: multiprocessing.Pool() raises a ValueError if the
http://hg.python.org/cpython/rev/1861683793d9

New changeset 815263546757 by Victor Stinner in branch '2.7':
Issue #12285: multiprocessing.Pool() raises a ValueError if the number of
http://hg.python.org/cpython/rev/815263546757

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12285>
_______________________________________

From report at bugs.python.org  Mon Jun 20 17:56:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 15:56:45 +0000
Subject: [issue12285] Unexpected behavior for 0 or negative processes in
	multiprocessing.pool()
In-Reply-To: <1307541329.07.0.743246465318.issue12285@psf.upfronthosting.co.za>
Message-ID: <1308585405.6.0.519602481893.issue12285@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/issue12285>
_______________________________________

From report at bugs.python.org  Mon Jun 20 18:01:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 16:01:06 +0000
Subject: [issue12213] BufferedRandom,
	BufferedRWPair: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1308585666.14.0.600401665588.issue12213@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

>> My patch tries to fix interlaced read-write by always calling flush(),
>
> Why do you need to call flush()? Can't you read from the buffer?

Hum, my patch does not always call flush of the reader and the writer. On read, it flushs the writer. On write, it "flushes" the reader (undo readahead).

It is maybe possible to do better (do something faster), but there should be some tricky cases with seek().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Mon Jun 20 18:23:35 2011
From: report at bugs.python.org (Erik Bray)
Date: Mon, 20 Jun 2011 16:23:35 +0000
Subject: [issue12375] Add packages_root to sys.path for hooks
In-Reply-To: <1308587015.96.0.883651483706.issue12375@psf.upfronthosting.co.za>
Message-ID: <1308587015.96.0.883651483706.issue12375@psf.upfronthosting.co.za>


New submission from Erik Bray <erik.m.bray at gmail.com>:

I just saw issue11637 [Add cwd to sys.path for hooks] and was reminded that this would also be useful (and in fact necessary if hook code is in a package that's under some root other than cwd).

On a related matter, the current use of Distribution.package_dir is confusing.  Sometimes it's assumed to be a string, though in other parts of the code it's assumed to be a dict to support multiple package dirs--something which I thought was going away.

----------
assignee: tarek
components: Distutils2
messages: 138737
nosy: alexis, eric.araujo, erik.bray, tarek
priority: normal
severity: normal
status: open
title: Add packages_root to sys.path for hooks
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12375>
_______________________________________

From report at bugs.python.org  Mon Jun 20 18:28:47 2011
From: report at bugs.python.org (Brian Larsen)
Date: Mon, 20 Jun 2011 16:28:47 +0000
Subject: [issue9998] find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1308587327.89.0.802836686134.issue9998@psf.upfronthosting.co.za>


Brian Larsen <balarsen at gmail.com> added the comment:

Hey I have this problem too.  I would love to see this fixed.

----------
nosy: +Brian.Larsen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Mon Jun 20 18:47:43 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 20 Jun 2011 16:47:43 +0000
Subject: [issue12213] BufferedRandom,
	BufferedRWPair: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1308588463.27.0.362776485573.issue12213@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/issue12213>
_______________________________________

From report at bugs.python.org  Mon Jun 20 18:50:14 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jun 2011 16:50:14 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1308588614.9.0.431416003607.issue9998@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +amaury.forgeotdarc, belopolsky -theller
title: find_library should search LD_LIBRARY_PATH on linux -> ctypes find_library should search LD_LIBRARY_PATH on linux

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Mon Jun 20 18:51:35 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 20 Jun 2011 16:51:35 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1308588695.44.0.799400947513.issue3067@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Victor, the issue for 3.x, which remains, is to improve the error message. I also suggested a doc change, though I would like Mark or Martin's comments before I would make it.

>But I think that the commit is just useless because we will have to wait until Python 2.7.3 is released, and if you want to support older Python versions, we will have to encode the locale explicitly to ASCII.

Exactly. 'Older versions' includes older versions of 2.7. This is why I suggested that making the change to 2.7 would be a feature addition, which is not permitted for the very reason you give. I think the commit should be reverted.

Certainly, when a another developer says "This patch should be rejected and not committed' after careful review, you should discuss, possibly on pydev, before committing.

----------
resolution: fixed -> 
status: closed -> open
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Mon Jun 20 19:02:20 2011
From: report at bugs.python.org (Nicolas Estibals)
Date: Mon, 20 Jun 2011 17:02:20 +0000
Subject: [issue12147] smtplib.send_message does not implement corectly rfc 2822
In-Reply-To: <1306050881.77.0.236550216984.issue12147@psf.upfronthosting.co.za>
Message-ID: <1308589340.01.0.602616517633.issue12147@psf.upfronthosting.co.za>


Nicolas Estibals <nicolas.estibals at gmail.com> added the comment:

Hi,

Treating this as a bug is a good news, if we don't user of the function will ask for python 3.3

I also think the part concerning the Sender header is pretty clear and we can fix it easily.

About the Resent-* fields, I'm not sure of the right thing to do. But I haven't found the mention of no automatic processing for them but I found that RFC 2822 specify more exactly how to use them.

Contrary to the other fields, they have to be in block and the more recent block have to be at the beginning of the mail, moreover they must not be reordered during transfer. Thus I think we have to consider the first block of Resent-* fields if present. (cf. RFC 2822 third paragraph in section 3.6 and appendix A.3) However perhaps we have to wait for an answer from email-sig.

I have one more concern about the send_mesage method: if the Bcc field is present this one is deleted, thus we lose information if we copy it in a sent directory for instance. What do you think about the idea that send_message method should not modify the message ? (The sent message should get rid of the Bcc header but not the one the user keep after using the method.)

Best regards.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12147>
_______________________________________

From report at bugs.python.org  Mon Jun 20 19:18:44 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 20 Jun 2011 17:18:44 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1308590324.27.0.125474218119.issue12352@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Thanks for reporting this.
There's indeed a bug which can lead to this deadlock.
Relevant code in Lib/multiprocessing/heap.py
- the BufferWrapper class uses a single Heap() shared among instances, protected by a mutex (threading.Lock), from which blocks are allocated
- when a BufferedWrapper is allocated, a multiprocessing.Finalizer is installed to free the corresponding block allocated from the Heap
- if another BufferedWrapper is garbage collected while the mutex protecting the Heap is held (in your case, while a new BufferedWrapper is allocated), the corresponding finalizer will try to free the block from the heap
- free tries to lock the mutex
- deadlock

The obvious solution is to use a recursive lock instead.
Could you try your application after changing:
"""
class Heap(object):

    _alignment = 8

    def __init__(self, size=mmap.PAGESIZE):     
        self._lastpid = os.getpid()     
        self._lock = threading.Lock()
"""

to
"""
class Heap(object):

    _alignment = 8

    def __init__(self, size=mmap.PAGESIZE):     
        self._lastpid = os.getpid()     
->      self._lock = threading.RLock()
"""

One could probably reproduce this by allocating and freeing many multiprocessing.Values, preferably with a lower GC threshold.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Mon Jun 20 19:22:39 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jun 2011 17:22:39 +0000
Subject: [issue12147] smtplib.send_message does not implement corectly rfc 2822
In-Reply-To: <1306050881.77.0.236550216984.issue12147@psf.upfronthosting.co.za>
Message-ID: <1308590559.24.0.633276031364.issue12147@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Section 3.6.6 says:

   Resent fields are strictly informational.  They MUST NOT be used in
   the normal processing of replies or other such automatic actions on
   messages.

Further, since there is no specified order for the headers within a block, there is no deterministic algorithmic way to determine where one block ends and the next begins.  A human (or a well thought out set of heuristics) can almost always figure it out, but it isn't guaranteed to be non-ambiguous.

The conclusion on the email-sig is that we should do the right thing when it is unambiguous (no or only one set of Resent- headers), and throw a ValueError if there are two copies of any Resent- header (refuse to guess).  For 3.3 we could implement heuristics and provide an option to turn them on, but that is an API change and so can't go into the 3.2 fix.

You have a good point about the method mutating the object passed to it.  This will probably come as a surprise even if documented, so it is indeed probably better to ensure that the object is unchanged after the call.  This can be done by mutating and restoring the object, but that would (I presume) not be thread safe.  Better would be a generator option to skip bcc fields, but that again is an API change.  I suppose that making a shallow copy of the Message object will be safe and not too inefficient.  Hopefully it will work :)

There are unresolved release blockers for the 3.2.1 RC, so we have at least a week to get this fixed and still make 3.2.1.  Do you want to update your patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12147>
_______________________________________

From report at bugs.python.org  Mon Jun 20 19:25:26 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jun 2011 17:25:26 +0000
Subject: [issue12147] smtplib.send_message does not implement corectly rfc 2822
In-Reply-To: <1306050881.77.0.236550216984.issue12147@psf.upfronthosting.co.za>
Message-ID: <1308590726.17.0.444030917002.issue12147@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that that RFC language is clearly directed at automatic processing on *receipt*, not during sending.  The RFC doesn't address automatic processing during sending, it leaves that the to the SMTP RFC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12147>
_______________________________________

From report at bugs.python.org  Mon Jun 20 19:39:14 2011
From: report at bugs.python.org (Ben Ranker)
Date: Mon, 20 Jun 2011 17:39:14 +0000
Subject: [issue12376] unittest.TextTestResult.__init__ breaks under complex
	__mro__
In-Reply-To: <1308591554.84.0.206840920137.issue12376@psf.upfronthosting.co.za>
Message-ID: <1308591554.84.0.206840920137.issue12376@psf.upfronthosting.co.za>


New submission from Ben Ranker <branker at emory.edu>:

TextTestResult.__init__(...) calls super(TextTestResult, self).__init__() with no args. If a custom TextTestResult descendant has a complex inheritance hierarchy that puts another class between TextTestResult and TestResult in the __mro__, then that class doesn't receive the common stream, descriptions, and verbosity args. If it needs them to function then the __init__ chain explodes.

See attached breakunit.py for an example of this.

----------
components: Library (Lib)
files: breakunit.py
messages: 138744
nosy: branker
priority: normal
severity: normal
status: open
title: unittest.TextTestResult.__init__ breaks under complex __mro__
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file22418/breakunit.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12376>
_______________________________________

From report at bugs.python.org  Mon Jun 20 19:50:14 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jun 2011 17:50:14 +0000
Subject: [issue12376] unittest.TextTestResult.__init__ breaks under complex
	__mro__
In-Reply-To: <1308591554.84.0.206840920137.issue12376@psf.upfronthosting.co.za>
Message-ID: <1308592214.64.0.921923331661.issue12376@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12376>
_______________________________________

From report at bugs.python.org  Mon Jun 20 20:30:47 2011
From: report at bugs.python.org (Nicolas Estibals)
Date: Mon, 20 Jun 2011 18:30:47 +0000
Subject: [issue12147] smtplib.send_message does not implement corectly rfc 2822
In-Reply-To: <1306050881.77.0.236550216984.issue12147@psf.upfronthosting.co.za>
Message-ID: <1308594647.01.0.280310623334.issue12147@psf.upfronthosting.co.za>


Nicolas Estibals <nicolas.estibals at gmail.com> added the comment:

I wasn't aware of the problem of guessing which are the correct Resent-* field, tthis does not seem to be that easy, however taking only the first one should be a good heuristic for next release.

I think we now agree on the "automatic processing" part, this only for the receipt part and section 3.6.6 mostly means that From, To, ... fields schould be considered (not the Resent-* fields) while sending an answer for example. For our case it schould be ok to use them as long as ther is no ambiguity (only one Resent-* block).

I'm ok for modifying my patch to reflect our discussion. You'll heard some news from it very soon. I'll also add the patch for not mutating the original message.

After 3.2.1, I'll work on implementing the few api change you discuss this will make the code very usable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12147>
_______________________________________

From report at bugs.python.org  Mon Jun 20 20:35:46 2011
From: report at bugs.python.org (John O'Connor)
Date: Mon, 20 Jun 2011 18:35:46 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <1308594946.97.0.00638919715523.issue5231@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
nosy: +jcon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Mon Jun 20 20:36:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Jun 2011 18:36:21 +0000
Subject: [issue12361] Memory Leak in File Logging
In-Reply-To: <1308440220.9.0.536544421463.issue12361@psf.upfronthosting.co.za>
Message-ID: <1308594981.83.0.24225927271.issue12361@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12361>
_______________________________________

From report at bugs.python.org  Mon Jun 20 20:48:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Jun 2011 18:48:45 +0000
Subject: [issue12374] Execution model should explain compile vs definition vs
	execution time
In-Reply-To: <1308582911.55.0.701954968644.issue12374@psf.upfronthosting.co.za>
Message-ID: <1308595725.63.0.0170449985139.issue12374@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, eric.araujo
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12374>
_______________________________________

From report at bugs.python.org  Mon Jun 20 20:50:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Jun 2011 18:50:47 +0000
Subject: [issue12375] Add packages_root to sys.path for hooks
In-Reply-To: <1308587015.96.0.883651483706.issue12375@psf.upfronthosting.co.za>
Message-ID: <1308595847.85.0.202297637343.issue12375@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1.

About packages_root usage: please file another bug.  I think new code to deal with packages_root was added, but internally packages_dir was not cleaned up.  Another problem is that these arguments affect all modules, not only packages, and are thus misnamed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12375>
_______________________________________

From report at bugs.python.org  Mon Jun 20 20:58:35 2011
From: report at bugs.python.org (John O'Connor)
Date: Mon, 20 Jun 2011 18:58:35 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1308596315.53.0.920862531122.issue10181@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
nosy: +jcon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Jun 20 21:20:43 2011
From: report at bugs.python.org (Erik Bray)
Date: Mon, 20 Jun 2011 19:20:43 +0000
Subject: [issue12377] Clean up packages_root option
In-Reply-To: <1308597643.18.0.622949056011.issue12377@psf.upfronthosting.co.za>
Message-ID: <1308597643.18.0.622949056011.issue12377@psf.upfronthosting.co.za>


New submission from Erik Bray <erik.m.bray at gmail.com>:

This issue was first mentioned in issue12375.  The Distribution.package_dir attribute (which also appears in a few commands) is not used in a consistent manner.  Some code expects it to be a string, while other code expects it to be a dict.

I believe the correct behavior now is for it to be a string, since only one root directory for Python packages is allowed in packaging.

Eric Araujo also points out that packages_root and the associated package_dir attribute are misnamed: They also point to the root for any Python modules.  I'm not sure what a better name would be though--I'm tempted to suggest "source_dir", but that seems a little broad since it doesn't necessarily include C extension source.

----------
assignee: tarek
components: Distutils2
messages: 138747
nosy: alexis, eric.araujo, erik.bray, tarek
priority: normal
severity: normal
status: open
title: Clean up packages_root option
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12377>
_______________________________________

From report at bugs.python.org  Mon Jun 20 21:21:17 2011
From: report at bugs.python.org (Erik Bray)
Date: Mon, 20 Jun 2011 19:21:17 +0000
Subject: [issue12375] Add packages_root to sys.path for hooks
In-Reply-To: <1308587015.96.0.883651483706.issue12375@psf.upfronthosting.co.za>
Message-ID: <1308597677.09.0.398545995834.issue12375@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

Added issue12377 for packages_root/package_dir cleanup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12375>
_______________________________________

From report at bugs.python.org  Mon Jun 20 21:23:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Jun 2011 19:23:52 +0000
Subject: [issue12377] Clean up use of packages_root/package_dir
In-Reply-To: <1308597643.18.0.622949056011.issue12377@psf.upfronthosting.co.za>
Message-ID: <1308597832.32.0.213423290785.issue12377@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I would rename it modules_root, but a related discussion last summer showed that using ?modules? to refer to pure Python modules, extension modules and Python packages was not 100% ideal for 100% of users.

----------
assignee: tarek -> eric.araujo
stage:  -> needs patch
title: Clean up packages_root option -> Clean up use of packages_root/package_dir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12377>
_______________________________________

From report at bugs.python.org  Mon Jun 20 21:24:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Jun 2011 19:24:57 +0000
Subject: [issue11637] Add cwd to sys.path for hooks
In-Reply-To: <1300828230.79.0.355779213126.issue11637@psf.upfronthosting.co.za>
Message-ID: <1308597897.17.0.947687862007.issue11637@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also #12375.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11637>
_______________________________________

From report at bugs.python.org  Mon Jun 20 21:26:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Jun 2011 19:26:27 +0000
Subject: [issue12240] Allow multiple setup_hooks
In-Reply-To: <1307026779.27.0.653754848212.issue12240@psf.upfronthosting.co.za>
Message-ID: <1308597987.11.0.0129627856981.issue12240@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The tests were failing on builbots with an ASCII locale.  The config files have to be opened with an explicit encoding='utf-8' argument.  Let?s remember it for the future :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12240>
_______________________________________

From report at bugs.python.org  Mon Jun 20 21:28:23 2011
From: report at bugs.python.org (Erik Bray)
Date: Mon, 20 Jun 2011 19:28:23 +0000
Subject: [issue12240] Allow multiple setup_hooks
In-Reply-To: <1307026779.27.0.653754848212.issue12240@psf.upfronthosting.co.za>
Message-ID: <1308598103.14.0.43465962397.issue12240@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

Good to know! The majority of my development is still on 2.x so it's easy to forget things like that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12240>
_______________________________________

From report at bugs.python.org  Mon Jun 20 21:44:24 2011
From: report at bugs.python.org (Joe Shaw)
Date: Mon, 20 Jun 2011 19:44:24 +0000
Subject: [issue12378] smtplib.SMTP_SSL leaks socket connections on SSL error
In-Reply-To: <1308599064.12.0.317669798103.issue12378@psf.upfronthosting.co.za>
Message-ID: <1308599064.12.0.317669798103.issue12378@psf.upfronthosting.co.za>


New submission from Joe Shaw <jshaw at itasoftware.com>:

Start a non-SSL server on port 2525:

$ python -m smtpd -n -c DebuggingServer localhost:2525

In another terminal, fire up a python interpreter and run the following code:

>>> import smtplib
>>> s = smtplib.SMTP_SSL("localhost", 2525)
[...]
ssl.SSLError: [Errno 1] _ssl.c:480: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

The underlying socket connection is still open, but you can't access it or close it:

$ lsof -P -p 76318 | grep 2525
Python  76318 joeshaw    3u  IPv4 0x09a9fb18       0t0      TCP localhost:64328->localhost:2525 (ESTABLISHED)

This wreaks havoc if you're trying to write a unit test using the smtpd module and asyncore in a thread and try to clean up after yourself.

The code inside SMTP_SSL looks something like this (on 2.6.5 anyway):

        def _get_socket(self, host, port, timeout):
            if self.debuglevel > 0: print>>stderr, 'connect:', (host, port)
            new_socket = socket.create_connection((host, port), timeout)
            new_socket = ssl.wrap_socket(new_socket, self.keyfile, self.certfile)
            self.file = SSLFakeFile(new_socket)
            return new_socket

Something like:

            new_socket = socket.create_connection((host, port), timeout)
            try:
                new_socket = ssl.wrap_socket(new_socket, self.keyfile, self.certfile)
            except:
                new_socket.close()
                raise
            self.file = SSLFakeFile(new_socket)
            return new_socket

I think will do the trick.

----------
components: Library (Lib)
messages: 138753
nosy: joeshaw
priority: normal
severity: normal
status: open
title: smtplib.SMTP_SSL leaks socket connections on SSL error
type: resource usage
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12378>
_______________________________________

From report at bugs.python.org  Mon Jun 20 21:59:42 2011
From: report at bugs.python.org (Joe Shaw)
Date: Mon, 20 Jun 2011 19:59:42 +0000
Subject: [issue12378] smtplib.SMTP_SSL leaks socket connections on SSL error
In-Reply-To: <1308599064.12.0.317669798103.issue12378@psf.upfronthosting.co.za>
Message-ID: <1308599982.47.0.566216705326.issue12378@psf.upfronthosting.co.za>


Joe Shaw <jshaw at itasoftware.com> added the comment:

>From some experimentation, closing the underlying socket isn't enough.  You also need to close the SSL socket, so you'd need to do something like:


new_socket = socket.create_connection((host, port), timeout)
ssl_socket = ssl.wrap_socket(new_socket, self.keyfile, self.certfile, do_handshake_on_connect=False)
try:
    ssl_socket.do_handshake()
except:
    ssl_socket.close()
    new_socket.close()
    raise
self.file = SSLFakeFile(ssl_socket)
return ssl_socket

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12378>
_______________________________________

From report at bugs.python.org  Mon Jun 20 22:00:54 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 20 Jun 2011 20:00:54 +0000
Subject: [issue12379] build outside source fail in head
In-Reply-To: <1308600053.87.0.881101721168.issue12379@psf.upfronthosting.co.za>
Message-ID: <1308600053.87.0.881101721168.issue12379@psf.upfronthosting.co.za>


New submission from Roumen Petrov <bugtrack at roumenpetrov.info>:

correct is -I$(srcdir)/Include

----------
components: Build
messages: 138755
nosy: rpetrov
priority: normal
severity: normal
status: open
title: build outside source fail in head
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12379>
_______________________________________

From report at bugs.python.org  Mon Jun 20 22:07:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jun 2011 20:07:08 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <E1QYkkU-0000zR-QP@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e72a2a60316f by Victor Stinner in branch '2.7':
Revert d370d609d09b as requested by Terry Jan Reedy:
http://hg.python.org/cpython/rev/e72a2a60316f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Mon Jun 20 22:17:25 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 20 Jun 2011 20:17:25 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1308601045.06.0.160297551643.issue12326@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

So people who say sys.platform shouldn't be used: what do you propose to do with Lib/plat-linux2 (or, more generally, Lib/plat-*)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Jun 20 22:26:52 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 20 Jun 2011 20:26:52 +0000
Subject: [issue9436] test_sysconfig failure: build a 32-bit Python a 64-bit OS
In-Reply-To: <1280591591.84.0.476083865565.issue9436@psf.upfronthosting.co.za>
Message-ID: <1308601612.12.0.955892098291.issue9436@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

The test case is bogus. Until is removed you could use CC='gcc -m32'.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9436>
_______________________________________

From report at bugs.python.org  Mon Jun 20 22:37:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 20:37:36 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1308602256.65.0.954663590968.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> what do you propose to do with Lib/plat-linux2
> (or, more generally, Lib/plat-*)?

What are these directories? Are they still used?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Jun 20 22:41:15 2011
From: report at bugs.python.org (Daniel Urban)
Date: Mon, 20 Jun 2011 20:41:15 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1308602475.01.0.0816492561334.issue11610@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

I've posted some comments on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Mon Jun 20 22:51:45 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 20 Jun 2011 20:51:45 +0000
Subject: [issue12363] test_signal.test_without_siginterrupt() sporadic
	failures on FreeBSD 6.4
In-Reply-To: <1308517732.02.0.248465302216.issue12363@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=fx-sXta_ox+tiTmuAjH6mOONtPQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The patch looks good to me.
In the subprocess, why not use the standard 0 exit code in case of success?
Also, points 1 and 3 could be handled simply by having the parent
process send a signal to the child (but this wouldn't address the
timeout issue).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12363>
_______________________________________

From report at bugs.python.org  Mon Jun 20 23:28:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jun 2011 21:28:06 +0000
Subject: [issue12363] test_signal.test_without_siginterrupt() sporadic
	failures on FreeBSD 6.4
In-Reply-To: <1308504105.8.0.100099791428.issue12363@psf.upfronthosting.co.za>
Message-ID: <E1QYm0q-0008PR-Im@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 968b9ff9a059 by Victor Stinner in branch 'default':
Close #12363: fix a race condition in siginterrupt() tests
http://hg.python.org/cpython/rev/968b9ff9a059

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12363>
_______________________________________

From report at bugs.python.org  Mon Jun 20 23:28:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 21:28:17 +0000
Subject: [issue12363] test_signal.test_without_siginterrupt() sporadic
	failures on FreeBSD 6.4
In-Reply-To: <1308504105.8.0.100099791428.issue12363@psf.upfronthosting.co.za>
Message-ID: <1308605297.79.0.691923235941.issue12363@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> In the subprocess, why not use the standard 0 exit code
> in case of success?

Something outside my code may exit Python with the code 0. Even if it unlikely, I prefer to use uncommon exit codes, to ensure that the child process executed "correctly" my code. A better check would be to write a specific pattern to stdout, and check stdout, but it would be overkill.

> Also, points 1 and 3 could be handled simply by having
> the parent process send a signal to the child
> (but this wouldn't address the timeout issue).

(Hum, points 1 and 3: "have only one thread" and "not touch signal handling of the parent process".)

True, but I would like to write a more reliable test, and I don't know how to synchronize two processes for this test case.

Because your first sentence was "The patch looks good to me.", let's try this new test in our buildbots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12363>
_______________________________________

From report at bugs.python.org  Tue Jun 21 00:23:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jun 2011 22:23:25 +0000
Subject: [issue12378] smtplib.SMTP_SSL leaks socket connections on SSL error
In-Reply-To: <1308599064.12.0.317669798103.issue12378@psf.upfronthosting.co.za>
Message-ID: <1308608605.23.0.946038882514.issue12378@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

2.6 is in security-fix-only mode.

By inspection the 2.7 and 3.x code have the same issue (though the 3.x code is very different, there still appears to be a lack of error recovery logic.

Joe, do you have any interest in writing a unit test for this?  I believe the necessary infrastructure already exists in test_smtpnet, though I'm not sure.

----------
nosy: +kasun, pitrou, r.david.murray
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12378>
_______________________________________

From report at bugs.python.org  Tue Jun 21 01:27:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 23:27:40 +0000
Subject: [issue12364] Timeout (1 hour) in test_concurrent_futures.tearDown()
	on sparc solaris10 gcc 3.x
In-Reply-To: <1308504315.81.0.454658658034.issue12364@psf.upfronthosting.co.za>
Message-ID: <1308612460.24.0.921861375514.issue12364@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Message on a stackoverflow thread:

"I have suffered from the same problem, even if connecting on localhost in python 2.7.1. After a day of debugging i found the cause and a workaround:

Cause: BaseProxy class has thread local storage which caches the connection, which is reused for future connections causing "broken pipe" errors even on creating a new Manager

Workaround: Delete the cached connection before reconnecting

if address in BaseProxy._address_to_local:
    del BaseProxy._address_to_local[self.address][0].connection"

http://stackoverflow.com/questions/3649458/broken-pipe-when-using-python-multiprocessing-managers-basemanager-syncmanager/5884967#5884967

---

See also maybe the (closed) issue #11663: multiprocessing doesn't detect killed processes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12364>
_______________________________________

From report at bugs.python.org  Tue Jun 21 01:37:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jun 2011 23:37:03 +0000
Subject: [issue12364] Timeout (1 hour) in test_concurrent_futures.tearDown()
	on sparc solaris10 gcc 3.x
In-Reply-To: <1308504315.81.0.454658658034.issue12364@psf.upfronthosting.co.za>
Message-ID: <1308613023.86.0.172607661613.issue12364@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Connection._send_bytes() has a comment about broken pipes:

    def _send_bytes(self, buf):
        # For wire compatibility with 3.2 and lower
        n = len(buf)
        self._send(struct.pack("=i", len(buf)))
        # The condition is necessary to avoid "broken pipe" errors
        # when sending a 0-length buffer if the other end closed the pipe.
        if n > 0:
            self._send(buf)

But the OSError(32, "Broken pipe") occurs on sending the buffer size (a chunk of 4 bytes: self._send(struct.pack("=i", len(buf)))), not on sending the buffer content.

See also maybe the (closed) issue #9205: Parent process hanging in multiprocessing if children terminate unexpectedly

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12364>
_______________________________________

From report at bugs.python.org  Tue Jun 21 02:42:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jun 2011 00:42:35 +0000
Subject: [issue12364] Timeout (1 hour) in test_concurrent_futures.tearDown()
	on sparc solaris10 gcc 3.x
In-Reply-To: <1308504315.81.0.454658658034.issue12364@psf.upfronthosting.co.za>
Message-ID: <1308616955.32.0.135782003461.issue12364@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ah, submit a new task after the manager shutdown fails with OSError(32, 'Broken pipe'). Example:
---------------
from multiprocessing.managers import BaseManager

class MathsClass(object):
    def foo(self):
        return 42

class MyManager(BaseManager):
    pass

MyManager.register('Maths', MathsClass)

if __name__ == '__main__':
    manager = MyManager()
    manager.start()
    maths = manager.Maths()
    maths.foo()
    manager.shutdown()
    try:
        maths.foo()
    finally:
        manager.shutdown()
---------------
This example doesn't hang, but this issue is about concurrent.futures, not multiprocessing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12364>
_______________________________________

From report at bugs.python.org  Tue Jun 21 03:05:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jun 2011 01:05:35 +0000
Subject: [issue12364] Timeout (1 hour) in test_concurrent_futures.tearDown()
	on sparc solaris10 gcc 3.x
In-Reply-To: <1308504315.81.0.454658658034.issue12364@psf.upfronthosting.co.za>
Message-ID: <1308618335.51.0.449763650808.issue12364@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, I think that I found a deadlock (or something like that):
----------------------------
import concurrent.futures
import faulthandler
import os
import signal
import time

def work(n):
    time.sleep(0.1)

def main():
    faulthandler.register(signal.SIGUSR1)
    print("pid: %s" % os.getpid())
    with concurrent.futures.ProcessPoolExecutor() as executor:
        for number, prime in executor.map(work, range(100)):
            print("shutdown")
            executor.shutdown()
            print("shutdown--")

if __name__ == '__main__':
    main()
----------------------------

Trace:
----------------------------
Thread 0x00007fbfc83bd700:
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 237 in wait
  File "/home/haypo/prog/HG/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00007fbfc8bbe700:
  File "/home/haypo/prog/HG/cpython/Lib/multiprocessing/queues.py", line 101 in put
  File "/home/haypo/prog/HG/cpython/Lib/concurrent/futures/process.py", line 268 in _queue_management_worker
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 710 in _bootstrap

Current thread 0x00007fbfcc2e3700:
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 237 in wait
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 851 in join
  File "/home/haypo/prog/HG/cpython/Lib/concurrent/futures/process.py", line 395 in shutdown
  File "/home/haypo/prog/HG/cpython/Lib/concurrent/futures/_base.py", line 570 in __exit__
  File "y.py", line 17 in main
  File "y.py", line 20 in <module>
----------------------------
There are two child processes, but both are zombies (displayed as "<defunct>" by ps). Send SIGUSR1 signal to the frozen process to display the traceback (thanks to faulthandler).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12364>
_______________________________________

From report at bugs.python.org  Tue Jun 21 05:50:10 2011
From: report at bugs.python.org (py.user)
Date: Tue, 21 Jun 2011 03:50:10 +0000
Subject: [issue12380] bytearray center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

>>> bytearray(b'abc').rjust(10, b'*')
bytearray(b'*******abc')
>>> bytearray(b'abc').rjust(10, bytearray(b'*'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be a byte string of length 1, not bytearray
>>>

----------
components: Interpreter Core
messages: 138769
nosy: py.user
priority: normal
severity: normal
status: open
title: bytearray center, ljust, rjust don't accept a bytearray as the fill character
type: behavior
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Tue Jun 21 05:51:00 2011
From: report at bugs.python.org (py.user)
Date: Tue, 21 Jun 2011 03:51:00 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1308628260.18.0.245909278758.issue12380@psf.upfronthosting.co.za>


Changes by py.user <port139 at yandex.ru>:


----------
title: bytearray center, ljust, rjust don't accept a bytearray as the fill character -> bytearray methods center, ljust, rjust don't accept a bytearray as the fill character

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Tue Jun 21 05:57:17 2011
From: report at bugs.python.org (py.user)
Date: Tue, 21 Jun 2011 03:57:17 +0000
Subject: [issue12381] bytearray methods count, find,
	index don't support None as in slice notation
In-Reply-To: <1308628637.29.0.156287318778.issue12381@psf.upfronthosting.co.za>
Message-ID: <1308628637.29.0.156287318778.issue12381@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

>>> bytearray(b'abc').count(bytearray(b''), None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: slice indices must be integers or None or have an __index__ method
>>> bytearray(b'abc').find(bytearray(b''), None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: slice indices must be integers or None or have an __index__ method
>>> bytearray(b'abc').index(bytearray(b''), None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: slice indices must be integers or None or have an __index__ method


and duplicate issues (endswith and startswith):

>>> bytearray(b'abc').endswith(bytearray(b''), None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: slice indices must be integers or None or have an __index__ method
>>> bytearray(b'abc').startswith(bytearray(b''), None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: slice indices must be integers or None or have an __index__ method
>>>

----------
components: Interpreter Core
messages: 138770
nosy: py.user
priority: normal
severity: normal
status: open
title: bytearray methods count, find, index don't support None as in slice notation
type: behavior
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12381>
_______________________________________

From report at bugs.python.org  Tue Jun 21 09:55:13 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 21 Jun 2011 07:55:13 +0000
Subject: [issue12263] punycode codec ignores the error handler argument
In-Reply-To: <1307229378.45.0.142684435058.issue12263@psf.upfronthosting.co.za>
Message-ID: <1308642913.61.0.110125028044.issue12263@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What's the point of disallowing the replace error handler? That's a slightly incompatible change, isn't it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12263>
_______________________________________

From report at bugs.python.org  Tue Jun 21 10:45:16 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 21 Jun 2011 08:45:16 +0000
Subject: [issue12365] URLopener should support context manager protocol
In-Reply-To: <1308582188.61.0.342800033159.issue12365@psf.upfronthosting.co.za>
Message-ID: <20110621084508.GA5725@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I forgot completely, but in Python3, Issue5418 had already added
support to addinfourl. It is now possible to write code like

import urllib.request

with urllib.request.urlopen('http://www.python.org') as req:
    res = req.read()

But yeah, unlike normal file objects, it not a strict requirement for
closing those objects as they will be closed when socket connection is
closed.

This is available only 3.x series and I think, a documentation update
should be fine and this report can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12365>
_______________________________________

From report at bugs.python.org  Tue Jun 21 11:38:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jun 2011 09:38:43 +0000
Subject: [issue12263] punycode codec ignores the error handler argument
In-Reply-To: <1307229378.45.0.142684435058.issue12263@psf.upfronthosting.co.za>
Message-ID: <1308649123.26.0.549653620786.issue12263@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, I forgot to give a little bit more details.

b'abc\xff-'.decode('punycode', 'ignore') and b'abc\xff-'.decode('punycode', 'replace') raise a UnicodeDecodeError: the error handler is just useless (ignored) here.

With my patch, b'abc\xff-'.decode('punycode', 'ignore') gives 'abc'. (If I change the code to accept replace) b'abc\xff-'.decode('punycode', 'replace') gives also 'abc', but 'replace' doesn't work correctly in the part after "-" contain illegal byte sequences.

For example, b'a\xff-\xffb\xffga\xff'.decode("punycode", "replace") gives 'a?', whereas I would expect 'a??' or 'a??'. b'a-bga\xff'.decode("punycode", "replace") gives 'a?' as b'a-bga'.decode("punycode", "replace"), whereas I would expect 'a??' or something like that.

> What's the point of disallowing the replace error handler?

It's just that I'm unable to patch punycode decoder to support the replace handler. Do you want to "implement" it?

> That's a slightly incompatible change, isn't it?

I don't think so because I consider that the punycode decoder never supported error handlers (other than strict) in Python 3.

What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12263>
_______________________________________

From report at bugs.python.org  Tue Jun 21 11:47:54 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 21 Jun 2011 09:47:54 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308590324.27.0.125474218119.issue12352@psf.upfronthosting.co.za>
Message-ID: <BANLkTimMnQMR8d+_hd=Qw9xvaiZuJsZBYg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> The obvious solution is to use a recursive lock instead.

Note that it's not really a solution, just a workaround to avoid
deadlocks, become this might lead to a corruption if free is called
while the heap is in an inconsistent state. I have to think some more
about a final solution, but I'd like to check first that this is
really what's happening here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Tue Jun 21 12:02:17 2011
From: report at bugs.python.org (greg.ath)
Date: Tue, 21 Jun 2011 10:02:17 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <BANLkTimMnQMR8d+_hd=Qw9xvaiZuJsZBYg@mail.gmail.com>
Message-ID: <BANLkTina0zFgq6ARLjEgHN2HGayUaFX9Kw@mail.gmail.com>


greg.ath <gathanase at gmail.com> added the comment:

Hi,

I also wonder about the performance cost of a recursive lock.

I am still unable to reproduce the bug in a simple script. Looking
closely to the gdb stack, there is that frame:
Frame 0x13be190, for file /usr/lib/python2.6/multiprocessing/heap.py, line 173
I understand that python reuses only the beginning of a memory block,
so it frees the remaining of the block.
I use both Value(c_int) and Value(c_double), which have different
sizes. That may explain that behaviour.

in heap.py, in the malloc function:
    167         self._lock.acquire()
    168         try:
    169             size = self._roundup(max(size,1), self._alignment)
    170             (arena, start, stop) = self._malloc(size)
    171             new_stop = start + size
    172             if new_stop < stop:
    173                 self._free((arena, new_stop, stop))

Thanks for your help

2011/6/21 Charles-Fran?ois Natali <report at bugs.python.org>:
>
> Charles-Fran?ois Natali <neologix at free.fr> added the comment:
>
>> The obvious solution is to use a recursive lock instead.
>
> Note that it's not really a solution, just a workaround to avoid
> deadlocks, become this might lead to a corruption if free is called
> while the heap is in an inconsistent state. I have to think some more
> about a final solution, but I'd like to check first that this is
> really what's happening here.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12352>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Tue Jun 21 12:28:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 21 Jun 2011 10:28:31 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1308652111.4.0.820493628091.issue12352@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Looking closely to the gdb stack, there is that frame:

Yeah, but it calls _free, which runs unlocked. That's not the problem.

> I am still unable to reproduce the bug in a simple script.

Try with this one:

"""
import multiprocessing.heap


tab = []

for i in range(100000):
    print(i)
    b = multiprocessing.heap.BufferWrapper(10)
    # create a circular reference (we want GC and not refcount collection when
    # the block goes out of scope)
    b.tab = tab
    tab.append(b)
    # drop buffers refcount to 0 to make them eligible to GC
    if i % 100 == 0:
        del tab
        tab = []
"""

It deadlocks pretty quickly (well, on my box).
And, as expected, disabling/enabling the GC inside malloc solves the problem.
I have to think a little bit more for a clean solution.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Tue Jun 21 12:32:43 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 21 Jun 2011 10:32:43 +0000
Subject: [issue12379] build outside source fail in head
In-Reply-To: <1308600053.87.0.881101721168.issue12379@psf.upfronthosting.co.za>
Message-ID: <1308652363.23.0.142702249467.issue12379@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

In which file there's an error? Could you elaborate a bit?

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12379>
_______________________________________

From report at bugs.python.org  Tue Jun 21 12:40:55 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 21 Jun 2011 10:40:55 +0000
Subject: [issue12296] Minor clarification in devguide
In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>
Message-ID: <1308652855.25.0.720073753512.issue12296@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

New semantics may also be something else than new classes or functions. New optional function arguments exposing new functionality, for example.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12296>
_______________________________________

From report at bugs.python.org  Tue Jun 21 13:02:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jun 2011 11:02:56 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1308654176.69.0.733792484541.issue12352@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I also wonder about the performance cost of a recursive lock.

An alternative is to disable the garbage collector in malloc():

    def malloc(self, size):
        ...
        enabled = gc.isenabled()
        if enabled:
            # disable the garbage collector to avoid a deadlock if block
            # is freed (if self.free() is called)
            gc.disable()
        try:
            with self._lock:
                size = self._roundup(max(size,1), self._alignment)
                ...
                return block
        finally:
            if enabled:
                gc.enable()

gc.disable() and gc.enable() just set an internal flag and so should be fast.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Tue Jun 21 13:10:43 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 21 Jun 2011 11:10:43 +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: <1308654643.47.0.601461588178.issue11909@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The patch looks good to me. It passes the old doctests tests and adds a new test case for what it's fixing.

----------
nosy: +petri.lehtinen, tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11909>
_______________________________________

From report at bugs.python.org  Tue Jun 21 13:11:57 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 21 Jun 2011 11:11:57 +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: <1308654717.91.0.620590072019.issue11869@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11869>
_______________________________________

From report at bugs.python.org  Tue Jun 21 13:27:15 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 21 Jun 2011 11:27:15 +0000
Subject: [issue11708] argparse: suggestion for formatting optional positional
	args
In-Reply-To: <1301372470.63.0.394832292121.issue11708@psf.upfronthosting.co.za>
Message-ID: <1308655635.39.0.582433401192.issue11708@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11708>
_______________________________________

From report at bugs.python.org  Tue Jun 21 13:27:30 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 21 Jun 2011 11:27:30 +0000
Subject: [issue11708] argparse: suggestion for formatting optional positional
	args
In-Reply-To: <1301372470.63.0.394832292121.issue11708@psf.upfronthosting.co.za>
Message-ID: <1308655650.21.0.143803157457.issue11708@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11708>
_______________________________________

From report at bugs.python.org  Tue Jun 21 14:12:17 2011
From: report at bugs.python.org (Robin Jarry)
Date: Tue, 21 Jun 2011 12:12:17 +0000
Subject: [issue12382] [msilib] Ambiguous exception message when trying to open
	a non existing MSI database
In-Reply-To: <1308658337.05.0.630810191443.issue12382@psf.upfronthosting.co.za>
Message-ID: <1308658337.05.0.630810191443.issue12382@psf.upfronthosting.co.za>


New submission from Robin Jarry <diabeteman at gmail.com>:

When trying to open a non existing MSI database, an obscure "unknown error 6e" is raised.

Could it be possible to get a more explicit message such as "File not found" or whatever ? 

Thanks :)

Here is a example:

--------------------------------

D:\>ll
total 0
drwxr-xr-x    4 tcinteg  Administ        0 Nov 30  2010 RECYCLER
drwxr-xr-x    0 tcinteg  Administ        0 Jul  6  2009 System Volume Information
drwxr-xr-x    4 tcinteg  Administ        0 Apr 29 16:03 TC
drwxr-xr-x    3 tcinteg  Administ        0 Apr 29 15:43 stgloc

D:\>python
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import msilib
>>> db = msilib.OpenDatabase("I_Do_Not_Exist.msi", msilib.MSIDBOPEN_READONLY)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_msi.MSIError: unknown error 6e
>>>

----------
components: Library (Lib)
messages: 138781
nosy: Robin.Jarry, loewis
priority: normal
severity: normal
status: open
title: [msilib] Ambiguous exception message when trying to open a non existing MSI database
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12382>
_______________________________________

From report at bugs.python.org  Tue Jun 21 14:18:05 2011
From: report at bugs.python.org (Robin Jarry)
Date: Tue, 21 Jun 2011 12:18:05 +0000
Subject: [issue12382] [msilib] Obscure exception message when trying to open a
	non-existent MSI database
In-Reply-To: <1308658337.05.0.630810191443.issue12382@psf.upfronthosting.co.za>
Message-ID: <1308658685.9.0.825543877665.issue12382@psf.upfronthosting.co.za>


Robin Jarry <diabeteman at gmail.com> added the comment:

changed the headline of the defect for something more meaningful :)

----------
title: [msilib] Ambiguous exception message when trying to open a non existing MSI database -> [msilib] Obscure exception message when trying to open a non-existent MSI database

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12382>
_______________________________________

From report at bugs.python.org  Tue Jun 21 14:23:07 2011
From: report at bugs.python.org (Tim Golden)
Date: Tue, 21 Jun 2011 12:23:07 +0000
Subject: [issue12382] [msilib] Obscure exception message when trying to open a
	non-existent MSI database
In-Reply-To: <1308658337.05.0.630810191443.issue12382@psf.upfronthosting.co.za>
Message-ID: <1308658987.37.0.114958365095.issue12382@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


----------
nosy: +markmcmahon, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12382>
_______________________________________

From report at bugs.python.org  Tue Jun 21 14:23:59 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 21 Jun 2011 12:23:59 +0000
Subject: [issue11695] Improve argparse usage/help customization
In-Reply-To: <1301234745.11.0.232414036754.issue11695@psf.upfronthosting.co.za>
Message-ID: <1308659039.87.0.409809226168.issue11695@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11695>
_______________________________________

From report at bugs.python.org  Tue Jun 21 14:30:43 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 21 Jun 2011 12:30:43 +0000
Subject: [issue11694] xdrlib raises ConversionError in inconsistent way
In-Reply-To: <1301224336.99.0.411299821684.issue11694@psf.upfronthosting.co.za>
Message-ID: <1308659443.48.0.0463387035602.issue11694@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

This seems like a bug worth fixing. The ConversionError exception has been documented, an there's an example in the docs that suggest that at least all packing fails with a ConversionError.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11694>
_______________________________________

From report at bugs.python.org  Tue Jun 21 14:57:31 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jun 2011 12:57:31 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1308661051.85.0.955286465166.issue12380@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What's the use case?  I'm inclined to reject this as not needed.

----------
nosy: +r.david.murray
type: behavior -> feature request
versions: +Python 3.3 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Tue Jun 21 15:00:31 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jun 2011 13:00:31 +0000
Subject: [issue12381] bytearray methods count, find,
	index don't support None as in slice notation
In-Reply-To: <1308628637.29.0.156287318778.issue12381@psf.upfronthosting.co.za>
Message-ID: <1308661231.79.0.692304664982.issue12381@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As Raymond said in another issue, someone should fix this once and for all by factoring this check out into a reusable method and making sure it is used everywhere.

----------
keywords: +easy
nosy: +r.david.murray
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12381>
_______________________________________

From report at bugs.python.org  Tue Jun 21 15:17:39 2011
From: report at bugs.python.org (Xuanji Li)
Date: Tue, 21 Jun 2011 13:17:39 +0000
Subject: [issue12381] bytearray methods count, find,
	index don't support None as in slice notation
In-Reply-To: <1308628637.29.0.156287318778.issue12381@psf.upfronthosting.co.za>
Message-ID: <1308662259.94.0.923017342011.issue12381@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/issue12381>
_______________________________________

From report at bugs.python.org  Tue Jun 21 15:51:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jun 2011 13:51:15 +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: <1308664275.31.0.00630692998267.issue11869@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Heh.  You are assuming we know how it "should" be used :)  It's pretty new yet, so I don't think we've figured that out.  But at at least how it works should be mentioned in the devguide.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11869>
_______________________________________

From report at bugs.python.org  Tue Jun 21 16:36:02 2011
From: report at bugs.python.org (Thomas Wouters)
Date: Tue, 21 Jun 2011 14:36:02 +0000
Subject: [issue12383] subprocess.Popen(..., env={}) fails to pass empty env.
In-Reply-To: <1308666962.05.0.419958842608.issue12383@psf.upfronthosting.co.za>
Message-ID: <1308666962.05.0.419958842608.issue12383@psf.upfronthosting.co.za>


New submission from Thomas Wouters <thomas at python.org>:

The addition of the _posixsubprocess module in 3.2 introduced a change of behaviour when passing an empty dict (or other false value besides None) as env:

python3.1 -c 'import subprocess; print(subprocess.Popen(["env"], env={}, stdout=subprocess.PIPE).communicate())'
(b'', None)

python3.2 -c 'import subprocess; print(subprocess.Popen(["env"], env={}, stdout=subprocess.PIPE).communicate())'
(b'LC_MONETARY=C\nSHELL=/bin/bash\nTERM=scr....', None)

The test for 'env' being the default (None) is not explicit enough.

----------
assignee: gregory.p.smith
components: Library (Lib)
files: subprocess.diff.txt
keywords: needs review, patch
messages: 138787
nosy: gregory.p.smith, twouters
priority: high
severity: normal
stage: patch review
status: open
title: subprocess.Popen(..., env={}) fails to pass empty env.
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22419/subprocess.diff.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12383>
_______________________________________

From report at bugs.python.org  Tue Jun 21 17:24:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Jun 2011 15:24:21 +0000
Subject: [issue12383] subprocess.Popen(..., env={}) fails to pass empty env.
In-Reply-To: <1308666962.05.0.419958842608.issue12383@psf.upfronthosting.co.za>
Message-ID: <E1QZ2oK-0005I3-Vh@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b5963fceddad by Victor Stinner in branch '3.2':
Close #12383: Fix subprocess module with env={}: don't copy the environment
http://hg.python.org/cpython/rev/b5963fceddad

New changeset 10ecf8576eb2 by Victor Stinner in branch 'default':
(merge 3.2) Close #12383: Fix subprocess module with env={}: don't copy the
http://hg.python.org/cpython/rev/10ecf8576eb2

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12383>
_______________________________________

From report at bugs.python.org  Tue Jun 21 17:28:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jun 2011 15:28:07 +0000
Subject: [issue12383] subprocess.Popen(..., env={}) fails to pass empty env.
In-Reply-To: <1308666962.05.0.419958842608.issue12383@psf.upfronthosting.co.za>
Message-ID: <1308670087.91.0.983971207084.issue12383@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The addition of the _posixsubprocess module in 3.2 introduced
> a change of behaviour when passing an empty dict
> (or other false value besides None) as env: ...

This bug was introduced by the commit (768722b2ae0a) introducing _posixsubprocess.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12383>
_______________________________________

From report at bugs.python.org  Tue Jun 21 17:28:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jun 2011 15:28:26 +0000
Subject: [issue12383] subprocess.Popen(..., env={}) fails to pass empty env.
In-Reply-To: <1308666962.05.0.419958842608.issue12383@psf.upfronthosting.co.za>
Message-ID: <1308670106.52.0.401917997912.issue12383@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Thanks for the fix, I added an unit test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12383>
_______________________________________

From report at bugs.python.org  Tue Jun 21 18:32:06 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jun 2011 16:32:06 +0000
Subject: [issue12383] subprocess.Popen(..., env={}) fails to pass empty env.
In-Reply-To: <1308666962.05.0.419958842608.issue12383@psf.upfronthosting.co.za>
Message-ID: <1308673926.47.0.439213539189.issue12383@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The test appears to be failing on the buildbots:

http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%203.2/builds/370

----------
nosy: +r.david.murray
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12383>
_______________________________________

From report at bugs.python.org  Tue Jun 21 19:53:05 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Tue, 21 Jun 2011 17:53:05 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1308678785.14.0.921603816558.issue10403@psf.upfronthosting.co.za>


Changes by Adam Woodbeck <adam.woodbeck at gmail.com>:


----------
nosy: +adam.woodbeck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Tue Jun 21 20:21:59 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 21 Jun 2011 18:21:59 +0000
Subject: [issue12383] subprocess.Popen(..., env={}) fails to pass empty env.
In-Reply-To: <1308666962.05.0.419958842608.issue12383@psf.upfronthosting.co.za>
Message-ID: <1308680519.28.0.0630055679181.issue12383@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

That failure is likely due to the environment being empty causing the subprocess to be unable to run.  Notice this error message further up:

test_empty_env (test.test_subprocess.ContextManagerTests) ... /srv/buildbot/buildarea/3.2.bolen-ubuntu/build/python: error while loading shared libraries: libpython3.2dm.so.1.0: cannot open shared object file: No such file or directory
FAIL

Looking at the environment at the top of the buildbot run log I'm not sure what it would be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12383>
_______________________________________

From report at bugs.python.org  Tue Jun 21 20:33:30 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 21 Jun 2011 18:33:30 +0000
Subject: [issue12381] bytearray methods count, find,
	index don't support None as in slice notation
In-Reply-To: <1308628637.29.0.156287318778.issue12381@psf.upfronthosting.co.za>
Message-ID: <1308681210.62.0.353737544771.issue12381@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12381>
_______________________________________

From report at bugs.python.org  Tue Jun 21 20:51:55 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Tue, 21 Jun 2011 18:51:55 +0000
Subject: [issue12378] smtplib.SMTP_SSL leaks socket connections on SSL error
In-Reply-To: <1308599064.12.0.317669798103.issue12378@psf.upfronthosting.co.za>
Message-ID: <1308682315.59.0.726920003887.issue12378@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/issue12378>
_______________________________________

From report at bugs.python.org  Tue Jun 21 21:09:55 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 21 Jun 2011 19:09:55 +0000
Subject: [issue12363] test_signal.test_without_siginterrupt() sporadic
	failures on FreeBSD 6.4
In-Reply-To: <1308605297.79.0.691923235941.issue12363@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=q8c5tfUqzY1ztk3AM0T6OL_+L3Q@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The test still fails on FreeBSD 7.2, Tiger and Debian parallel:

"""
======================================================================
FAIL: test_siginterrupt_on (test.test_signal.SiginterruptTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_signal.py",
line 379, in test_siginterrupt_on
    self.assertTrue(interrupted)
AssertionError: False is not true

======================================================================
FAIL: test_without_siginterrupt (test.test_signal.SiginterruptTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_signal.py",
line 372, in test_without_siginterrupt
    self.assertTrue(interrupted)
AssertionError: False is not true
"""

Here's a sample strace output on my Linux box when it fails:

2120  21:00:18.755448 rt_sigaction(SIGALRM, {0x810b332, [], 0}, NULL,
8) = 0 <0.000019>
2120  21:00:18.755690 alarm(1)          = 0 <0.000024>
2120  21:00:18.755803 read(3,  <unfinished ...>
[...]
2120  21:00:19.755811 <... read resumed> 0xb72cad90, 1) = ?
ERESTARTSYS (To be restarted) <0.999973>
2120  21:00:19.755864 --- SIGALRM (Alarm clock) @ 0 (0) ---
2120  21:00:19.756094 sigreturn()       = ? (mask now []) <0.000019>
2120  21:00:19.756434 alarm(1)          = 0 <0.000023>
2120  21:00:19.756547 read(3,  <unfinished ...>

sigaction is called without SA_RESTART, but the syscall is restarted anyway...
Apart from removing those tests, I don't see what we can do here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12363>
_______________________________________

From report at bugs.python.org  Tue Jun 21 21:52:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jun 2011 19:52:30 +0000
Subject: [issue12383] subprocess.Popen(..., env={}) fails to pass empty env.
In-Reply-To: <1308666962.05.0.419958842608.issue12383@psf.upfronthosting.co.za>
Message-ID: <1308685950.25.0.921692055547.issue12383@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

On Mac OS X, the failure is different:

======================================================================
FAIL: test_empty_env (test.test_subprocess.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_subprocess.py", line 400, in test_empty_env
    self.assertEqual(stdout.strip(), b"0")
AssertionError: b'1' != b'0'

http://www.python.org/dev/buildbot/all/builders/PPC%20Tiger%203.x/builds/2059/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12383>
_______________________________________

From report at bugs.python.org  Tue Jun 21 21:52:31 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Tue, 21 Jun 2011 19:52:31 +0000
Subject: [issue12378] smtplib.SMTP_SSL leaks socket connections on SSL error
In-Reply-To: <1308599064.12.0.317669798103.issue12378@psf.upfronthosting.co.za>
Message-ID: <1308685951.39.0.318380326275.issue12378@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

Just a note after running Joe's example. smtplib is affected by this issue in 3.x, but the example produces different results in 3.x: smtpd doesn't keep the connection open due to UnicodeDecodeError when the data from the ssl handshake cannot be decoded as utf-8:

error: uncaptured python exception, closing channel <__main__.SMTPChannel connected 127.0.0.1:34160 at 0xb739a4cc> (<class 'UnicodeDecodeError'>:'utf8' codec can't decode bytes in position 13-14: invalid continuation byte [/mnt/data/catalin/hacking/cpython/default/Lib/asyncore.py|read|83] [/mnt/data/catalin/hacking/cpython/default/Lib/asyncore.py|handle_read_event|442] [/mnt/data/catalin/hacking/cpython/default/Lib/asynchat.py|handle_read|190] [/mnt/data/catalin/hacking/cpython/default/Lib/smtpd.py|collect_incoming_data|278])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12378>
_______________________________________

From report at bugs.python.org  Tue Jun 21 21:58:14 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 21 Jun 2011 19:58:14 +0000
Subject: [issue12383] subprocess.Popen(..., env={}) fails to pass empty env.
In-Reply-To: <1308666962.05.0.419958842608.issue12383@psf.upfronthosting.co.za>
Message-ID: <1308686294.76.0.625744471862.issue12383@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Maybe test_empty_env() should pass LD_LIBRARY_PATH to child process.

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12383>
_______________________________________

From report at bugs.python.org  Tue Jun 21 21:59:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Jun 2011 19:59:04 +0000
Subject: [issue12383] subprocess.Popen(..., env={}) fails to pass empty env.
In-Reply-To: <1308666962.05.0.419958842608.issue12383@psf.upfronthosting.co.za>
Message-ID: <E1QZ76E-0005iz-Vg@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8d46e84cd812 by Victor Stinner in branch '3.2':
Issue #12383: skip test_empty_env() if compiled is compiled in shared mode
http://hg.python.org/cpython/rev/8d46e84cd812

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12383>
_______________________________________

From report at bugs.python.org  Tue Jun 21 22:00:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Jun 2011 20:00:04 +0000
Subject: [issue12383] subprocess.Popen(..., env={}) fails to pass empty env.
In-Reply-To: <1308666962.05.0.419958842608.issue12383@psf.upfronthosting.co.za>
Message-ID: <E1QZ77C-0005lh-QJ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d1d5a7392e39 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12383: skip test_empty_env() if compiled is compiled in
http://hg.python.org/cpython/rev/d1d5a7392e39

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12383>
_______________________________________

From report at bugs.python.org  Tue Jun 21 22:00:41 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Jun 2011 20:00:41 +0000
Subject: [issue12384] difflib.SequenceMatcher and Match: code and doc bugs
In-Reply-To: <1308686441.84.0.396418173173.issue12384@psf.upfronthosting.co.za>
Message-ID: <1308686441.84.0.396418173173.issue12384@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

The basic problem: in 2.6, a namedtuple was introduced to difflib

from collections import namedtuple as _namedtuple
Match = _namedtuple('Match', 'a b size')

and used for the return values of SeqeunceMatcher.get_longest_match and .get_matching_blocks. Code, docstrings, and docs were only partially updated to match.

Code:

    def get_matching_blocks(self):
        """Return list of triples describing matching subsequences.
        Each triple is of the form (i, j, n), and means that
        ...'''
        if self.matching_blocks is not None:
            return self.matching_blocks
        ...
        self.matching_blocks = non_adjacent
        return map(Match._make, self.matching_blocks)

The two returns are different because only the second was changed.
The obvious fix is to change the first to match. Or perhaps self.matching_blocks (an undocumented cache) should be the map object.

Docstring and doc for .find_longest_match():

Both start
 "Find longest matching block ... returns (i, j, k) such that ... "
Doc (bug not docstring) explicitly says at the *bottom* of the entry "This method returns a named tuple Match(a, b, size)."
which is different from (i,j,n). For 2.7, the note is preceded by "Changed in version 2.6:"
The examples show the change before it is described.

I think that the current return should be accurately described at the *top* of the entry, not the bottom. 2.7 would then end with "Changed in version 2.6: return Match instead of tuple."

Docstring and doc for .get_matching_blocks():

See code snippet above for beginning of text. Unlike .find_longest_match, there is no mention of the changed return.

In 2.7, it is a list of Match triples.
In 3.x, it is an iterable (Map) of Match triples, because of the change in map() return.

For the latter reason, the example in the 3.x doc must be changed to
>>> list(s.get_matching_blocks())

The docstring was already changed to pass doctest. The untested doc was not.

I am not sure how to properly document the use of a namedtuple in the stdlib. Raymond, what do you think?

----------
assignee: rhettinger
components: Documentation, Library (Lib)
messages: 138799
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: difflib.SequenceMatcher and Match: code and doc bugs
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12384>
_______________________________________

From report at bugs.python.org  Tue Jun 21 22:01:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jun 2011 20:01:38 +0000
Subject: [issue12383] subprocess.Popen(..., env={}) fails to pass empty env.
In-Reply-To: <1308666962.05.0.419958842608.issue12383@psf.upfronthosting.co.za>
Message-ID: <1308686498.28.0.977455320296.issue12383@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Maybe test_empty_env() should pass LD_LIBRARY_PATH to child process.

The idea of the test is to test an empty environment: if we pass one variable, it is no more an empty environment.

I changed the test to skip it if Python is compiled in shared mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12383>
_______________________________________

From report at bugs.python.org  Tue Jun 21 22:15:36 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 21 Jun 2011 20:15:36 +0000
Subject: [issue12263] punycode codec ignores the error handler argument
In-Reply-To: <1308649123.26.0.549653620786.issue12263@psf.upfronthosting.co.za>
Message-ID: <4E00FBE6.9070800@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Oh, I forgot to give a little bit more details.
> 
> b'abc\xff-'.decode('punycode', 'ignore') and
> b'abc\xff-'.decode('punycode', 'replace') raise a UnicodeDecodeError:
> the error handler is just useless (ignored) here.

That's not my point:

b"foo".decode("punycode","replace")

currently succeeds, but raises an UnicodeError under the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12263>
_______________________________________

From report at bugs.python.org  Tue Jun 21 22:20:17 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 21 Jun 2011 20:20:17 +0000
Subject: [issue12379] build outside source fail in head
In-Reply-To: <1308600053.87.0.881101721168.issue12379@psf.upfronthosting.co.za>
Message-ID: <1308687617.07.0.700167761968.issue12379@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

cf. http://hg.python.org/cpython/rev/0d0ca6f95d9d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12379>
_______________________________________

From report at bugs.python.org  Tue Jun 21 23:05:57 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 21 Jun 2011 21:05:57 +0000
Subject: [issue12363] test_signal.test_without_siginterrupt() sporadic
	failures on FreeBSD 6.4
In-Reply-To: <BANLkTi=q8c5tfUqzY1ztk3AM0T6OL_+L3Q@mail.gmail.com>
Message-ID: <BANLkTikJfz_OWBPP+TA2tSgQ=dr6O=bfUA@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

Duh, don't know what I was thinking: the syscall is not restarted
(even though ERESTARTSYS is displayed by strace): the real problem is
that the 3s timeout to communicate is not enough, because spawning a
new interpreter can take a long time (Antoine created an issue some
time ago about the high number of syscalls per import). If it takes
more than 1s, the test will fail.
Also, I guess it's worst on FreeBSD because subprocess.Popen uses
close_fds=True by default, and FreeBSD has a huge default
_SC_OPEN_MAX.
I've attached a patch passing close_fds=False to spawn_python, and
running the test only once, because otherwise this would require a
timeout quite large.

----------
Added file: http://bugs.python.org/file22420/test_siginterrupt.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12363>
_______________________________________
-------------- next part --------------
diff -r 10ecf8576eb2 Lib/test/test_signal.py
--- a/Lib/test/test_signal.py	Tue Jun 21 17:24:21 2011 +0200
+++ b/Lib/test/test_signal.py	Tue Jun 21 23:03:18 2011 +0200
@@ -337,21 +337,19 @@
             if interrupt is not None:
                 signal.siginterrupt(signal.SIGALRM, interrupt)
 
-            # run the test twice
-            for loop in range(2):
-                # send a SIGALRM in a second (during the read)
-                signal.alarm(1)
-                try:
-                    # blocking call: read from a pipe without data
-                    os.read(r, 1)
-                except OSError as err:
-                    if err.errno != errno.EINTR:
-                        raise
-                else:
-                    sys.exit(2)
+            # send a SIGALRM in a second (during the read)
+            signal.alarm(1)
+            try:
+                # blocking call: read from a pipe without data
+                os.read(r, 1)
+            except OSError as err:
+                if err.errno != errno.EINTR:
+                    raise
+            else:
+                sys.exit(2)
             sys.exit(3)
         """ % (interrupt,)
-        with spawn_python('-c', code) as process:
+        with spawn_python('-c', code, close_fds=False) as process:
             try:
                 stdout, stderr = process.communicate(timeout=3.0)
             except subprocess.TimeoutExpired:

From report at bugs.python.org  Tue Jun 21 23:08:52 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 21 Jun 2011 21:08:52 +0000
Subject: [issue12363] test_signal.test_without_siginterrupt() sporadic
	failures on FreeBSD 6.4
In-Reply-To: <1308504105.8.0.100099791428.issue12363@psf.upfronthosting.co.za>
Message-ID: <1308690532.81.0.873702219913.issue12363@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file22421/test_siginterrupt.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12363>
_______________________________________

From report at bugs.python.org  Tue Jun 21 23:09:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 21 Jun 2011 21:09:06 +0000
Subject: [issue12363] test_signal.test_without_siginterrupt() sporadic
	failures on FreeBSD 6.4
In-Reply-To: <1308504105.8.0.100099791428.issue12363@psf.upfronthosting.co.za>
Message-ID: <1308690546.26.0.0621129848676.issue12363@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22420/test_siginterrupt.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12363>
_______________________________________

From report at bugs.python.org  Tue Jun 21 23:09:23 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 21 Jun 2011 21:09:23 +0000
Subject: [issue12363] test_signal.test_without_siginterrupt() sporadic
	failures on FreeBSD 6.4
In-Reply-To: <1308504105.8.0.100099791428.issue12363@psf.upfronthosting.co.za>
Message-ID: <1308690563.53.0.0554883864188.issue12363@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12363>
_______________________________________

From report at bugs.python.org  Wed Jun 22 00:15:26 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 21 Jun 2011 22:15:26 +0000
Subject: [issue12384] difflib.SequenceMatcher and Match: code and doc bugs
In-Reply-To: <1308686441.84.0.396418173173.issue12384@psf.upfronthosting.co.za>
Message-ID: <1308694526.39.0.0458922008932.issue12384@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'll take a look at this when I get a chance (est. two weeks).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12384>
_______________________________________

From report at bugs.python.org  Wed Jun 22 00:18:55 2011
From: report at bugs.python.org (py.user)
Date: Tue, 21 Jun 2011 22:18:55 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1308694735.31.0.718850393156.issue12380@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

all other methods support it and it's right

>>> barr = bytearray(b'abcd*')
>>> barr.center(len(barr) * 4, barr[-1:])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be a byte string of length 1, not bytearray
>>> b = b'abcd*'
>>> b.center(len(b) * 4, b[-1:])
b'*******abcd*********'
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Wed Jun 22 00:21:46 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Tue, 21 Jun 2011 22:21:46 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1308694906.16.0.899861582269.issue10403@psf.upfronthosting.co.za>


Adam Woodbeck <adam.woodbeck at gmail.com> added the comment:

I grepped the documentation in the cpython repository and replaced all mentions of "member(s)" with "attribute(s)" where I felt appropriate.  I left mentions of "members" related to structs or any C documentation alone as I'm less confident of their terminology (I'm new around here).

I used "methods and attribute" in io.rst because BufferedIOBase included one attribute and several methods.  My terminology may be off, but I felt this was the correct replacement of "members."

Please review the patch and critique it as necessary.

----------
keywords: +patch
Added file: http://bugs.python.org/file22422/issue10403.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Wed Jun 22 00:51:48 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jun 2011 22:51:48 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1308696708.46.0.838378103844.issue12380@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

A bytearray is for working with mutable data.  We don't support using it in all places that the non-mutable data types can be used.  You can code your example like this:

   barr.center(len(barr) * 4, bytes([barr[-1]]))

I realize that isn't particularly pretty, but that has more to do with the fact that indexing bytes gives you ints in Python 3 than it does with whether or not bytearray is accepted.

The data type of the arguments to the method have no necessary relationship with the datatype of the object.

You may have more success arguing that the fill character for both bytearray and bytes should be allowed to be an int.

I think this whole topic is better addressed in a forum such as python-ideas.  I agree that the bytes interface is a bit wonky in places, but I think that if changes are going to be made a consensus needs to be developed on what changes to make.  I believe some conversations about this have already taken place, and so far I don't think there are any consensus proposals.

So, I'm going to close this issue.  But please join (or start, if necessary) the discussion on this wider topic in the appropriate forum.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Wed Jun 22 01:35:00 2011
From: report at bugs.python.org (py.user)
Date: Tue, 21 Jun 2011 23:35:00 +0000
Subject: [issue12385] the help for bytearray.maketrans describes
	bytes.maketrans
In-Reply-To: <1308699300.81.0.100519829981.issue12385@psf.upfronthosting.co.za>
Message-ID: <1308699300.81.0.100519829981.issue12385@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

help(bytearray.maketrans)

maketrans(...)
    B.maketrans(frm, to) -> translation table
    
    Return a translation table (a bytes object of length 256)
    suitable for use in bytes.translate where each byte in frm is
    mapped to the byte at the same position in to.
    The strings frm and to must be of the same length.

----------
assignee: docs at python
components: Documentation
messages: 138808
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: the help for bytearray.maketrans describes bytes.maketrans
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12385>
_______________________________________

From report at bugs.python.org  Wed Jun 22 01:46:02 2011
From: report at bugs.python.org (py.user)
Date: Tue, 21 Jun 2011 23:46:02 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1308699962.51.0.664691351711.issue12380@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

> A bytearray is for working with mutable data.  We don't support using > it in all places that the non-mutable data types can be used.

>>> bytearray(b'abcd').strip(bytearray(b'da'))
bytearray(b'bc')
>>>

.translate, .find, .partition, ...

>>> bytearray(b'.').join((bytearray(b'a'), bytearray(b'b')))
bytearray(b'a.b')
>>> bytearray(b'.').join((b'a', b'b'))
bytearray(b'a.b')
>>>

all these methods could use only bytes objects

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Wed Jun 22 02:15:48 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jun 2011 00:15:48 +0000
Subject: [issue12385] the help for bytearray.maketrans describes
	bytes.maketrans
In-Reply-To: <1308699300.81.0.100519829981.issue12385@psf.upfronthosting.co.za>
Message-ID: <1308701748.32.0.270180869754.issue12385@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  I wonder why we have two copies of this method.

Well, given that we do, the best fix for the docs would be to say "for use in the bytes or bytearray translate method" in both this docstring and the bytes.maketrans docstring.

----------
nosy: +r.david.murray
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12385>
_______________________________________

From report at bugs.python.org  Wed Jun 22 02:25:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jun 2011 00:25:38 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1308702338.93.0.303374677514.issue12380@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

All right, let's get some other opinions from people who have actually worked with the bytearray and bytes code (and Terry because he cares about APIs).

----------
nosy: +haypo, ncoghlan, pitrou, rhettinger, terry.reedy
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Wed Jun 22 02:49:19 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 22 Jun 2011 00:49:19 +0000
Subject: [issue12307] Inconsistent formatting of section titles in PEP 0
In-Reply-To: <1307685038.6.0.993227913919.issue12307@psf.upfronthosting.co.za>
Message-ID: <1308703759.87.0.870990734475.issue12307@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Yeah, the extra space results in a different formatting.  Compare "Index by Category" with "Numerical Index".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12307>
_______________________________________

From report at bugs.python.org  Wed Jun 22 03:36:35 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 22 Jun 2011 01:36:35 +0000
Subject: [issue12308] Add link to PEP 0 for topical index in wiki
In-Reply-To: <1307685938.0.0.639002265247.issue12308@psf.upfronthosting.co.za>
Message-ID: <1308706595.8.0.846438947422.issue12308@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I had considered that, but thought it would be better to leave the topical index open for editing to a broader audience.  If it's in PEP 0 then only committers could make changes.

I do like the idea of using keywords from the PEPs themselves, but that would again preclude anyone but committers from defining the topics.

I brought up the index on the core-mentorship list in April and got a favorable response from Guido and Nick.

Nick: "Indeed, a very good idea.  The wiki is probably a good place for it (since it will need to be manually maintained, and there's no reason to restrict that privilege to core devs)" and a link in PEP 0 to the wiki page would be easy to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12308>
_______________________________________

From report at bugs.python.org  Wed Jun 22 07:09:12 2011
From: report at bugs.python.org (Simon)
Date: Wed, 22 Jun 2011 05:09:12 +0000
Subject: [issue8093] IDLE processes don't close
In-Reply-To: <1268090491.77.0.977887093309.issue8093@psf.upfronthosting.co.za>
Message-ID: <1308719351.99.0.416642437555.issue8093@psf.upfronthosting.co.za>


Simon <simon.buchan.nz at gmail.com> added the comment:

Not sure if this is related, but for me none of the F5 processes (command line "pythonw.exe -c __import__('idlelib.run').run.main(True) <num>") ever exit on either 2.7.2 or 3.2.1rc1.

----------
nosy: +Simon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8093>
_______________________________________

From report at bugs.python.org  Wed Jun 22 07:40:36 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 22 Jun 2011 05:40:36 +0000
Subject: [issue12379] build outside source fail in head
In-Reply-To: <1308600053.87.0.881101721168.issue12379@psf.upfronthosting.co.za>
Message-ID: <1308721236.4.0.389718451179.issue12379@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Benjamin: The mentioned commit is yours, so you probably have the best understanding of this change.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12379>
_______________________________________

From report at bugs.python.org  Wed Jun 22 08:27:40 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 22 Jun 2011 06:27:40 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1308602256.65.0.954663590968.issue12326@psf.upfronthosting.co.za>
Message-ID: <4E018B52.8030603@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> What are these directories? 

Look and see for yourself.

> Are they still used?

Sure. If you do "import DLFCN", it will come from that directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Wed Jun 22 08:50:05 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 22 Jun 2011 06:50:05 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1308725405.98.0.200356819465.issue12326@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Wed Jun 22 08:51:56 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 22 Jun 2011 06:51:56 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1308725516.07.0.845695175196.issue12380@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Wed Jun 22 12:37:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Jun 2011 10:37:10 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1308601045.06.0.160297551643.issue12326@psf.upfronthosting.co.za>
Message-ID: <20110622123708.126cef04@msiwind>


Antoine Pitrou <pitrou at free.fr> added the comment:

> So people who say sys.platform shouldn't be used: what do you propose to
> do with Lib/plat-linux2 (or, more generally, Lib/plat-*)?

These directories look useless to me.
(IIRC, putting an obvious syntax error there does not trigger any failure
in the regression suite, showing that they are never imported)

That's orthogonal to whether sys.platform should be used or not, however.
During the language summit, someone (Marc-Andr?) brought an interesting
point: the platform does external calls to system commands such as "uname",
which can be time-consuming.

We should at least document an example of using sys.platform.startswith()
rather than exact comparison.

Regards

Antoine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Wed Jun 22 13:02:27 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 22 Jun 2011 11:02:27 +0000
Subject: [issue7434] general pprint rewrite
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1308740547.67.0.27434118775.issue7434@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +aronacher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7434>
_______________________________________

From report at bugs.python.org  Wed Jun 22 13:03:20 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 22 Jun 2011 11:03:20 +0000
Subject: [issue7434] general pprint rewrite
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1308740600.51.0.195432361152.issue7434@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Link to Armin's work on a pprint improvement based on a Ruby pprint tool:  https://github.com/mitsuhiko/prettyprint

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7434>
_______________________________________

From report at bugs.python.org  Wed Jun 22 13:12:45 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 22 Jun 2011 11:12:45 +0000
Subject: [issue7434] general pprint rewrite
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1308741165.77.0.744969963504.issue7434@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Mine still lies here:

https://bitbucket.org/langacore/nattyprint

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7434>
_______________________________________

From report at bugs.python.org  Wed Jun 22 13:19:36 2011
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Wed, 22 Jun 2011 11:19:36 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1308741576.2.0.545821723449.issue9561@psf.upfronthosting.co.za>


Micha? G?rny <mgorny at gentoo.org> added the comment:

Now that installing scripts with unicode characters was fixed, shall I open a separate bug for writing egg files with utf8 chars in author name?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Wed Jun 22 13:22:25 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 22 Jun 2011 11:22:25 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

This part of install_distinf.run():

    if install_data.get_resources_out() != []:
        resources_path = os.path.join(self.distinfo_dir,
                                      'RESOURCES')
        logger.info('creating %s', resources_path)
        with open(resources_path, 'wb') as f:
            writer = csv.writer(f, delimiter=',',
                                lineterminator='\n',
                                quotechar='"')
            for tuple in install_data.get_resources_out():
                writer.writerow(tuple)

fails at the writerow line:

creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/METADATA
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/INSTALLER
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/REQUESTED
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/RESOURCES
Traceback (most recent call last):
  File "/tmp/venv/bin/pysetup3", line 5, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.3/packaging/run.py", line 678, in main
    return dispatcher()
  File "/usr/local/lib/python3.3/packaging/run.py", line 667, in __call__
    return func(self, self.args)
  File "/usr/local/lib/python3.3/packaging/run.py", line 204, in wrapper
    return f(*args, **kwargs)
  File "/usr/local/lib/python3.3/packaging/run.py", line 247, in _install
    if install_local_project(target):
  File "/usr/local/lib/python3.3/packaging/install.py", line 125, in install_local_project
    return _run_install_from_dir(path)
  File "/usr/local/lib/python3.3/packaging/install.py", line 160, in _run_install_from_dir
    func(source_dir)
  File "/usr/local/lib/python3.3/packaging/install.py", line 90, in _run_packaging_install
    dist.run_command('install_dist')
  File "/usr/local/lib/python3.3/packaging/dist.py", line 761, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python3.3/packaging/command/install_dist.py", line 526, in run
    self.run_command(cmd_name)
  File "/usr/local/lib/python3.3/packaging/command/cmd.py", line 329, in run_command
    self.distribution.run_command(command)
  File "/usr/local/lib/python3.3/packaging/dist.py", line 761, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python3.3/packaging/command/install_distinfo.py", line 116, in run
    writer.writerow(tuple)
TypeError: 'str' does not support the buffer interface


I think the open(resources_path) should use 'w' rather than 'wb' as the open mode.

Relevant part of setup.cfg:

resources =
    virtualenvwrapper.sh = {scripts}

I know I can put it in the scripts = section, but I'm testing having something in resources, which ought to work ...

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 138821
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: normal
severity: normal
status: open
title: packaging fails in install_distinfo when writing RESOURCES
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Wed Jun 22 15:17:24 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 22 Jun 2011 13:17:24 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1308748644.11.0.313730375221.issue9561@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Please file a separate issue.

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Wed Jun 22 15:34:23 2011
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Wed, 22 Jun 2011 13:34:23 +0000
Subject: [issue12087] install_egg_info fails with UnicodeEncodeError depending
	on locale
In-Reply-To: <1305548495.94.0.944889224247.issue12087@psf.upfronthosting.co.za>
Message-ID: <1308749663.85.0.0952027640105.issue12087@psf.upfronthosting.co.za>


Changes by Micha? G?rny <mgorny at gentoo.org>:


----------
nosy: +mgorny

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12087>
_______________________________________

From report at bugs.python.org  Wed Jun 22 17:23:33 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jun 2011 15:23:33 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1308756213.34.0.699176937201.issue12326@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Indeed, the lib/plat- directories should continue to work just fine using linux3, correct?  Or using linux, if we change sys.platform.

(Note: just because we don't import them in the test suite doesn't mean that user code in the field isn't using them...I got a few (trivial it is true, but...) hits from google code search on DLFCN.)

Changing sys.platform as Martin suggests seems like the least painful solution to me.

Note, however, that we have skips in the tests suite that do care about, for example, the FreeBSD OS major version.  FreeBSD does sometimes fix the bugs we've discovered...but as someone else pointed out, this doesn't necessarily happen at a major release boundary, we just use that in the test skipping because it is the easiest thing for us to do.  If sys.platform no longer included the OS major version, the test skips would probably end up being made more accurate.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Wed Jun 22 17:44:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 22 Jun 2011 15:44:37 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1308757477.27.0.280363007723.issue12326@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> the platform does external calls to system commands such as "uname",
I guess it?s the platform module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Wed Jun 22 19:02:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 22 Jun 2011 17:02:01 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1308762121.77.0.409377930672.issue12181@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a patch.

----------
keywords: +needs review, patch
stage:  -> patch review
Added file: http://bugs.python.org/file22423/kevent_openbsd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Wed Jun 22 19:32:04 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 22 Jun 2011 17:32:04 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1308763924.48.0.840196952522.issue12181@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22423/kevent_openbsd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Wed Jun 22 19:48:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Jun 2011 17:48:29 +0000
Subject: [issue1874] email parser does not register a defect for invalid
	Content-Transfer-Encoding on multipart messages
In-Reply-To: <1200767841.97.0.882225337338.issue1874@psf.upfronthosting.co.za>
Message-ID: <E1QZRXP-0007f5-GP@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5a2602939d5d by R David Murray in branch 'default':
#1874: detect invalid multipart CTE and report it as a defect.
http://hg.python.org/cpython/rev/5a2602939d5d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1874>
_______________________________________

From report at bugs.python.org  Wed Jun 22 19:53:19 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jun 2011 17:53:19 +0000
Subject: [issue1874] email parser does not register a defect for invalid
	Content-Transfer-Encoding on multipart messages
In-Reply-To: <1200767841.97.0.882225337338.issue1874@psf.upfronthosting.co.za>
Message-ID: <1308765199.53.0.735948775729.issue1874@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for the patches.  I didn't use them, but they were helpful references.

This is in a grey area between a bug and a feature request.  The fact is, though, that for the most part the email module currently doesn't make extra effort to detect defects, it just reports the ones it has to work around.  The only exception I found to this was taking an extra step to report a defect that represented a defect in the constructed model of the message.

Now, in the next version of email (targeted for 3.3), one of the design goals is to detect as many RFC conformance defects as practical.  So, I'm treating this as a feature request, and have checked it in to 3.3 (default).

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed
type: behavior -> feature request
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1874>
_______________________________________

From report at bugs.python.org  Wed Jun 22 19:59:58 2011
From: report at bugs.python.org (Jacob VB)
Date: Wed, 22 Jun 2011 17:59:58 +0000
Subject: [issue12387] IDLE save hotkey problem
In-Reply-To: <1308765598.77.0.79184481064.issue12387@psf.upfronthosting.co.za>
Message-ID: <1308765598.77.0.79184481064.issue12387@psf.upfronthosting.co.za>


New submission from Jacob VB <Jacob.Andrew.VB at gmail.com>:

IDLE (for Python 3.2) fails to save using the ctrl-s keyboard shortcut when caps-lock is enabled, and instead only saves when ctrl-shift-s is pressed.
When caps-lock is disabled, all shortcuts work normally.

----------
components: IDLE
messages: 138828
nosy: Jacob.VB
priority: normal
severity: normal
status: open
title: IDLE save hotkey problem
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12387>
_______________________________________

From report at bugs.python.org  Wed Jun 22 20:00:31 2011
From: report at bugs.python.org (Jacob VB)
Date: Wed, 22 Jun 2011 18:00:31 +0000
Subject: [issue12387] IDLE save keyboard shortcut problem
In-Reply-To: <1308765598.77.0.79184481064.issue12387@psf.upfronthosting.co.za>
Message-ID: <1308765631.32.0.0608293754346.issue12387@psf.upfronthosting.co.za>


Changes by Jacob VB <Jacob.Andrew.VB at gmail.com>:


----------
title: IDLE save hotkey problem -> IDLE save keyboard shortcut problem

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12387>
_______________________________________

From report at bugs.python.org  Wed Jun 22 20:01:24 2011
From: report at bugs.python.org (Jacob VB)
Date: Wed, 22 Jun 2011 18:01:24 +0000
Subject: [issue12387] IDLE save keyboard shortcut problem
In-Reply-To: <1308765598.77.0.79184481064.issue12387@psf.upfronthosting.co.za>
Message-ID: <1308765684.68.0.457713959543.issue12387@psf.upfronthosting.co.za>


Jacob VB <Jacob.Andrew.VB at gmail.com> added the comment:

IDLE (for Python 3.2) fails to save using the ctrl-s keyboard shortcut when caps-lock is enabled, and instead only saves when ctrl-shift-s is pressed.
When caps-lock is disabled, all shortcuts work normally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12387>
_______________________________________

From report at bugs.python.org  Wed Jun 22 21:10:39 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 22 Jun 2011 19:10:39 +0000
Subject: [issue12313] make install misses test dirs for packaging and email
	modules
In-Reply-To: <1307722082.95.0.13819638115.issue12313@psf.upfronthosting.co.za>
Message-ID: <1308769839.0.0.609645889219.issue12313@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The changes have been checked in by Barry and David, so I'm closing this issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12313>
_______________________________________

From report at bugs.python.org  Wed Jun 22 21:29:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Jun 2011 19:29:10 +0000
Subject: [issue12383] subprocess.Popen(..., env={}) fails to pass empty env.
In-Reply-To: <1308666962.05.0.419958842608.issue12383@psf.upfronthosting.co.za>
Message-ID: <E1QZT6l-0000DF-0D@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset da3af4b131d7 by Victor Stinner in branch '3.2':
Issue #12383: fix test_empty_env() of subprocess on Mac OS X
http://hg.python.org/cpython/rev/da3af4b131d7

New changeset 29819072855a by Victor Stinner in branch 'default':
(merge 3.2) Issue #12383: fix test_empty_env() of subprocess on Mac OS X
http://hg.python.org/cpython/rev/29819072855a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12383>
_______________________________________

From report at bugs.python.org  Wed Jun 22 22:16:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Jun 2011 20:16:36 +0000
Subject: [issue12363] test_signal.test_without_siginterrupt() sporadic
	failures on FreeBSD 6.4
In-Reply-To: <1308504105.8.0.100099791428.issue12363@psf.upfronthosting.co.za>
Message-ID: <E1QZTql-0004UT-AF@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset aff0a7b0cb12 by Victor Stinner in branch 'default':
Issue #12363: improve siginterrupt() tests
http://hg.python.org/cpython/rev/aff0a7b0cb12

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12363>
_______________________________________

From report at bugs.python.org  Wed Jun 22 22:20:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jun 2011 20:20:43 +0000
Subject: [issue12363] test_signal.test_without_siginterrupt() sporadic
	failures on FreeBSD 6.4
In-Reply-To: <1308504105.8.0.100099791428.issue12363@psf.upfronthosting.co.za>
Message-ID: <1308774043.84.0.77027062194.issue12363@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Apart from removing those tests, I don't see what we can do here.

The previous version of the test rarely failed (only sometimes on the FreeBSD 6.4 buildbox). We may revert my commits to restore the previous test if the new tests fail more often.

> the real problem is that the 3s timeout to communicate is not
> enough, because spawning a new interpreter can take a long time

Right, I added a basic synchronization code to wait until the beginning of the test. Let see if it is better or worse ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12363>
_______________________________________

From report at bugs.python.org  Wed Jun 22 22:37:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jun 2011 20:37:31 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1308775051.69.0.870026270403.issue12181@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Why did you remove your patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Wed Jun 22 23:14:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jun 2011 21:14:56 +0000
Subject: [issue9642] #ifdef and mbcs: don't check
	for	defined(HAVE_USABLE_WCHAR_T)
In-Reply-To: <1282219348.43.0.267719038373.issue9642@psf.upfronthosting.co.za>
Message-ID: <1308777296.18.0.478796268236.issue9642@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

have_mbcs.patch: use HAVE_MBCS define instead of different tests to check if the MBCS codec can be used or not. HAVE_MBCS is defined in unicodeobject.h by:

#if defined(MS_WINDOWS) && defined(HAVE_USABLE_WCHAR_T)
#  define HAVE_MBCS
#endif

> > We should just check that we are compiling under Windows:

> -1, see above. In the long run, it would be really good if Python
> supported a four-byte Py_UNICODE on Windows - people keep asking
> for it.

MBCS functions of the Python API are always available on Windows without my patch. I don't know if it's correct or not. Using my patch, they are not available if HAVE_USABLE_WCHAR_T is not defined.

Support 32 bits Py_UNICODE on Windows requires a lot of work because in *many* places (everywhere?) Py_UNICODE* is used as wchar_t*. But it is not the topic of this issue :-)

----------
Added file: http://bugs.python.org/file22424/have_mbcs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9642>
_______________________________________

From report at bugs.python.org  Wed Jun 22 23:37:42 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 22 Jun 2011 21:37:42 +0000
Subject: [issue12388] cannot specify recursive extra_files in packaging
	setup.cfg
In-Reply-To: <1308778662.94.0.774064324312.issue12388@psf.upfronthosting.co.za>
Message-ID: <1308778662.94.0.774064324312.issue12388@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

When given a section like

[files]
extra_files =
    somedir/**

only the first-level contents of somedir and included in the tarball created when you run "pysetup3 run sdist". Ideally, the entire tree below somedir should be included.

A real example is referenced in https://gist.github.com/1041219

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 138836
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: normal
severity: normal
status: open
title: cannot specify recursive extra_files in packaging setup.cfg
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12388>
_______________________________________

From report at bugs.python.org  Thu Jun 23 01:04:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Jun 2011 23:04:38 +0000
Subject: [issue12383] subprocess.Popen(..., env={}) fails to pass empty env.
In-Reply-To: <1308666962.05.0.419958842608.issue12383@psf.upfronthosting.co.za>
Message-ID: <E1QZWTM-0000jh-Vu@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 52c5f80122dd by Victor Stinner in branch '3.2':
Issue #12383: skip test_empty_env() of subprocess on Windows
http://hg.python.org/cpython/rev/52c5f80122dd

New changeset 93cd98782f47 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12383: skip test_empty_env() of subprocess on Windows
http://hg.python.org/cpython/rev/93cd98782f47

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12383>
_______________________________________

From report at bugs.python.org  Thu Jun 23 01:07:36 2011
From: report at bugs.python.org (Vladimir Rutsky)
Date: Wed, 22 Jun 2011 23:07:36 +0000
Subject: [issue12389] typo in urllib: missing space after dot at sentence end
In-Reply-To: <1308784056.05.0.196763325672.issue12389@psf.upfronthosting.co.za>
Message-ID: <1308784056.05.0.196763325672.issue12389@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky <altsysrq at gmail.com>:

There is a typo in urllib module documentation: missing space after dot at sentence end. Please see attached path for details.

----------
assignee: docs at python
components: Documentation
files: urllib-typo-space-after-dot.patch
keywords: patch
messages: 138838
nosy: docs at python, rutsky
priority: normal
severity: normal
status: open
title: typo in urllib: missing space after dot at sentence end
versions: Python 2.7
Added file: http://bugs.python.org/file22425/urllib-typo-space-after-dot.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12389>
_______________________________________

From report at bugs.python.org  Thu Jun 23 02:03:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Jun 2011 00:03:06 +0000
Subject: [issue12389] typo in urllib: missing space after dot at sentence end
In-Reply-To: <1308784056.05.0.196763325672.issue12389@psf.upfronthosting.co.za>
Message-ID: <E1QZXNw-0004eC-Vt@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a0ad25ca772b by R David Murray in branch '2.7':
#12389: fix missing space at sentence end.
http://hg.python.org/cpython/rev/a0ad25ca772b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12389>
_______________________________________

From report at bugs.python.org  Thu Jun 23 02:03:37 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Jun 2011 00:03:37 +0000
Subject: [issue12389] typo in urllib: missing space after dot at sentence end
In-Reply-To: <1308784056.05.0.196763325672.issue12389@psf.upfronthosting.co.za>
Message-ID: <1308787417.21.0.0594815933421.issue12389@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12389>
_______________________________________

From report at bugs.python.org  Thu Jun 23 02:07:56 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Jun 2011 00:07:56 +0000
Subject: [issue12387] IDLE save keyboard shortcut problem
In-Reply-To: <1308765598.77.0.79184481064.issue12387@psf.upfronthosting.co.za>
Message-ID: <1308787676.92.0.868643327965.issue12387@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +kbk, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12387>
_______________________________________

From report at bugs.python.org  Thu Jun 23 02:08:33 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jun 2011 00:08:33 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1308787713.82.0.965364938515.issue12380@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

After thinking about this awhile, I see the key sentence of David's reply as "The data type of the arguments to the method have no necessary relationship with the datatype of the object." While true in general, in it not true with respect to corresponing text (string) and byte(array) methods. String parameters of strings methods become byte parameters of byte(array) methods. In the other hand, I think I agree with David's application to byte versus bytearray methods. I might change my mind after further examination of the methods in question. But for the present, I would not change the code.

Or would I? Here is a reason not to change. Example:

for byt in (b'abc', bytearray(b'cdef'), b'xye')
  yield byt.rjust(10,b'-')

Making the type of constant args depend on the type of the base object would make generic byte/bytearray functions more difficult. We already have this problem with writing functions that work with bytes and text in 3.x. It is a big nuisance that is only justified by the benefits of not mixing bytes and text. I do not think we should extend the nuisance to byte and bytearray functions, especially without a strong use case.

I marked this for 'documentation' because I think the doc for some of the str methods might be improved and that the reference to them in the bytes/bytearray definitely needs more. Doc changes would apply to 3.2 also.

"Bytes and bytearray objects, being ?strings of bytes?, have all methods found on strings, with the exception ... " 

should be followed by something like. 

"If the string method has a string parameter, the corresponding byte/bytearray method has a corresponding byte parameter."

(to match the reported current behavior).

I have not yet looked at doc strings. I did not unmark 'Interpreter core' because I have not looked at all of p.u's examples to be sure that I like *all* of the current behaviors.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
resolution: rejected -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Thu Jun 23 02:13:52 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jun 2011 00:13:52 +0000
Subject: [issue12387] IDLE save keyboard shortcut problem
In-Reply-To: <1308765598.77.0.79184481064.issue12387@psf.upfronthosting.co.za>
Message-ID: <1308788032.77.0.678860510431.issue12387@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: http://bugs.python.org/msg138829

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12387>
_______________________________________

From report at bugs.python.org  Thu Jun 23 02:24:54 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jun 2011 00:24:54 +0000
Subject: [issue12387] IDLE save keyboard shortcut problem
In-Reply-To: <1308765598.77.0.79184481064.issue12387@psf.upfronthosting.co.za>
Message-ID: <1308788694.0.0.205767934969.issue12387@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

(The message I deleted was a duplicate of the original).
Verified with 3.2.0 on WinXP (Jacob, I/O issues, including keyboard, especially need system specified. What is yours? If Windows, this might be Windows-specific.)

With CAPS LOCK on, Cntl-N, Cntl-O, Cntl-P, Alt-M, Alt-C work.
Cntl-S, Cntl-Shift-S, Alt-Shift-S, Cntl-Q do not.
(All of above from File menu). So behavior is variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12387>
_______________________________________

From report at bugs.python.org  Thu Jun 23 02:35:11 2011
From: report at bugs.python.org (Jacob VB)
Date: Thu, 23 Jun 2011 00:35:11 +0000
Subject: [issue12387] IDLE save keyboard shortcut problem
In-Reply-To: <1308765598.77.0.79184481064.issue12387@psf.upfronthosting.co.za>
Message-ID: <1308789311.78.0.517662848555.issue12387@psf.upfronthosting.co.za>


Jacob VB <Jacob.Andrew.VB at gmail.com> added the comment:

I'm running Windows 7 Home Premium 64-bit, on an Alienware M17x (a laptop) using the built-in keyboard.

It's definitely possible that the problem is Windows-specific; perhaps it has to do with the fact that when caps lock is on the shift modifier seems to invert the case back to lowercase; although I don't know how it would affect it in that way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12387>
_______________________________________

From report at bugs.python.org  Thu Jun 23 03:01:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Jun 2011 01:01:51 +0000
Subject: [issue10354] tempfile.template is broken
In-Reply-To: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za>
Message-ID: <E1QZYIn-0008RA-Go@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset eafe8c7f7049 by R David Murray in branch 'default':
#10354: remove last public mentions of 'template' and comment as private.
http://hg.python.org/cpython/rev/eafe8c7f7049

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10354>
_______________________________________

From report at bugs.python.org  Thu Jun 23 03:03:55 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Jun 2011 01:03:55 +0000
Subject: [issue10354] tempfile.template is broken
In-Reply-To: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za>
Message-ID: <1308791035.68.0.328495002095.issue10354@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I have removed the last mentions of template from the docs and docstrings, and added a comment that it is a private variable despite its name.  I do not see a reason to break backward compatibility just to have a leading underscore in the name.  If there is disagreement on this we can reopen the issue.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10354>
_______________________________________

From report at bugs.python.org  Thu Jun 23 03:19:30 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Jun 2011 01:19:30 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1308791970.73.0.291273444028.issue9921@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is a patch that I think describes the algorithm correctly, based on the comments in the module, with a clarifying parenthetical to cover the non-obvious consequence of that algorithm.

----------
versions: +Python 3.3 -Python 3.1
Added file: http://bugs.python.org/file22426/os.path.join-doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Thu Jun 23 03:27:19 2011
From: report at bugs.python.org (Chris Withers)
Date: Thu, 23 Jun 2011 01:27:19 +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: <1308792439.1.0.442468385998.issue2202@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Just got bitten by this as well, what still needs to happen with the patch?

----------
keywords:  -easy
nosy: +cjw296

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Thu Jun 23 03:44:11 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Jun 2011 01:44:11 +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: <1308793451.53.0.124456053166.issue2202@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

One question is whether this is a bug fix or a feature request.

Other than that, I'd like to see the test classes collapsed into a single test class, considering that each one only has a single test in it.  Probably ProxyAuthTests should be refactored so that the stuff that is currently in setUp is a method that gets called with appropriate parameters instead, and all the new tests moved on to ProxyAuthTests.

Also, a version of the patch for 3.x would be most helpful, since it won't port cleanly due to the renamings.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Thu Jun 23 04:11:08 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 23 Jun 2011 02:11:08 +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: <1308795068.15.0.609944117089.issue2202@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Yes, it is a feature. Sorry that I have not paid attention to this. The Windows (IIS) part led me to delay as I did not have any to test. Let me take this up and see through it in 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Thu Jun 23 05:02:46 2011
From: report at bugs.python.org (Joesph)
Date: Thu, 23 Jun 2011 03:02:46 +0000
Subject: [issue12390] urllib.parse.urlencode encoding lists as strings
In-Reply-To: <1308798165.99.0.217904560432.issue12390@psf.upfronthosting.co.za>
Message-ID: <1308798165.99.0.217904560432.issue12390@psf.upfronthosting.co.za>


New submission from Joesph <someone3x7 at gmail.com>:

"""
Per the documentation urlencode is supposed to encode a structure returned by parse_qs back to a query string. However, urlencode appears to not be processing the lists associated with each key.
Example:
"""
import urllib.parse
dictQuery = urllib.parse.parse_qs('a=b&b=c&c=d&c=e',
                                  strict_parsing=True,
                                  encoding='iso8859-1')
assert isinstance(dictQuery,dict)
assert isinstance(dictQuery['a'],list)
strQuery = urllib.parse.urlencode(dictQuery, encoding='iso8859-1')
print(strQuery)
""" 
Outputs: a=%5B%27b%27%5D&c=%5B%27d%27%2C+%27e%27%5D&b=%5B%27c%27%5D
Which means: a=['b']&c=['d', 'e']&b=['c']
Expected: a=b&c=d&c=e&b=c
"""

----------
components: Library (Lib)
messages: 138850
nosy: someone3x7
priority: normal
severity: normal
status: open
title: urllib.parse.urlencode encoding lists as strings
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12390>
_______________________________________

From report at bugs.python.org  Thu Jun 23 05:33:04 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 23 Jun 2011 03:33:04 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1308799984.34.0.190995064997.issue12380@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/issue12380>
_______________________________________

From report at bugs.python.org  Thu Jun 23 05:41:41 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 23 Jun 2011 03:41:41 +0000
Subject: [issue12390] urllib.parse.urlencode encoding lists as strings
In-Reply-To: <1308798165.99.0.217904560432.issue12390@psf.upfronthosting.co.za>
Message-ID: <1308800501.91.0.478521987056.issue12390@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I see you missed the doseq parameter which is applicable in this case.

print(urllib.parse.urlencode(dictQuery, encoding='iso8859-1',doseq=True))
a=b&c=d&c=e&b=c

----------
nosy: +orsenthil
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12390>
_______________________________________

From report at bugs.python.org  Thu Jun 23 08:28:47 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 23 Jun 2011 06:28:47 +0000
Subject: [issue10206] python program starting with unmatched quote spews
	spaces to stdout
In-Reply-To: <1288123288.86.0.422520379457.issue10206@psf.upfronthosting.co.za>
Message-ID: <1308810527.54.0.536647638193.issue10206@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

I'm unable to reproduce this. I checked out the commit 65614:18989ad44636 (corresponding to r85814, right?), built and ran python -c "'", but didn't get a space flood on my face. Just a normal SyntaxError.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Thu Jun 23 08:55:07 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 23 Jun 2011 06:55:07 +0000
Subject: [issue10206] python program starting with unmatched quote spews
	spaces to stdout
In-Reply-To: <1288123288.86.0.422520379457.issue10206@psf.upfronthosting.co.za>
Message-ID: <1308812107.89.0.441116166519.issue10206@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I remember that I could reproduce it at the time. The issue was indeed
fixed in r85904.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Thu Jun 23 08:58:45 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 23 Jun 2011 06:58:45 +0000
Subject: [issue10206] python program starting with unmatched quote spews
	spaces to stdout
In-Reply-To: <1288123288.86.0.422520379457.issue10206@psf.upfronthosting.co.za>
Message-ID: <1308812325.98.0.434264865478.issue10206@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

By checking out the parent of r85904 I now can reproduce this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Thu Jun 23 09:11:17 2011
From: report at bugs.python.org (Chris Withers)
Date: Thu, 23 Jun 2011 07:11:17 +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: <1308813077.4.0.979835811246.issue2202@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Hmm, I'd argue it's a bug:

  File "/usr/lib64/python2.5/urllib2.py", line 972, in get_algorithm_impls
    return H, KD
UnboundLocalError: local variable 'H' referenced before assignment

...does not say anything like:

"The digest authentication scheme you have requested is not supported"

Now, as to whether it's a bug that 'MD5-sess' isn't supported is a tougher call. The XXX indicates the intention was certainly for it to be supported...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Thu Jun 23 09:25:24 2011
From: report at bugs.python.org (Joesph)
Date: Thu, 23 Jun 2011 07:25:24 +0000
Subject: [issue12390] urllib.parse.urlencode encoding lists as strings
In-Reply-To: <1308798165.99.0.217904560432.issue12390@psf.upfronthosting.co.za>
Message-ID: <1308813924.59.0.255314754897.issue12390@psf.upfronthosting.co.za>


Joesph <someone3x7 at gmail.com> added the comment:

Hrm, yes. 'Tis what I get for working while sick.

----------
resolution: invalid -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12390>
_______________________________________

From report at bugs.python.org  Thu Jun 23 09:30:21 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 23 Jun 2011 07:30:21 +0000
Subject: [issue12390] urllib.parse.urlencode encoding lists as strings
In-Reply-To: <1308798165.99.0.217904560432.issue12390@psf.upfronthosting.co.za>
Message-ID: <1308814221.29.0.534005742877.issue12390@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Joseph, resolution applies for the bug not the process. tc. :)

----------
resolution: accepted -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12390>
_______________________________________

From report at bugs.python.org  Thu Jun 23 09:34:30 2011
From: report at bugs.python.org (Brian Brazil)
Date: Thu, 23 Jun 2011 07:34:30 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1308814470.58.0.979385244706.issue9921@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

David's change sounds good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Thu Jun 23 09:36:39 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 23 Jun 2011 07:36:39 +0000
Subject: [issue10206] python program starting with unmatched quote spews
	spaces to stdout
In-Reply-To: <1288123288.86.0.422520379457.issue10206@psf.upfronthosting.co.za>
Message-ID: <1308814599.2.0.523011296522.issue10206@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached a test case. The patch is against the current default tip.

----------
Added file: http://bugs.python.org/file22427/issues10206_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Thu Jun 23 09:43:36 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 23 Jun 2011 07:43:36 +0000
Subject: [issue12391] packaging install fails to clean up temp files
In-Reply-To: <1308815016.03.0.685993126745.issue12391@psf.upfronthosting.co.za>
Message-ID: <1308815016.03.0.685993126745.issue12391@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

There are a number of places in packaging.install where temporary directories are created, but never cleaned up:

1. In _move_files, if no destination path is passed in, one is created using mkdtemp(), but it's not clear where this would be deleted. Moreover, it's never called without a path and not part of the public API, so it would make sense to always expect a destination to be passed in (and update the docstring to match)

2. install_local_project, in the case of an archive, unpacks it into a mkdtemp()'d directory, but never deletes that directory later.

3. install_dists() also calls mkdtemp() if a path is not passed in, but it's not clear where this would be deleted. This should be changed to always require a path to be passed in. The install_from_infos accepts None as an install path and passes that to install_dists, but why are we being so generous? It's not asking a lot to be given an explicit path to install to.

Note: the DistInfo class in packaging.pypi.dist also does this kind of thing (in the download and unpack methods) - it would seem sensible to make similar changes there.

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 138860
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: normal
severity: normal
status: open
title: packaging install fails to clean up temp files
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12391>
_______________________________________

From report at bugs.python.org  Thu Jun 23 09:51:11 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 23 Jun 2011 07:51:11 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1308815471.03.0.811315072779.issue12386@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Thu Jun 23 11:49:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Jun 2011 09:49:14 +0000
Subject: [issue12363] test_signal.test_without_siginterrupt() sporadic
	failures on FreeBSD 6.4
In-Reply-To: <1308504105.8.0.100099791428.issue12363@psf.upfronthosting.co.za>
Message-ID: <1308822554.6.0.404868087193.issue12363@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

All Python 3.x buildbots are green (except FreeBSD 7.2, but it's not related to this issue). Let close this issue.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12363>
_______________________________________

From report at bugs.python.org  Thu Jun 23 11:57:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Jun 2011 09:57: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: <E1QZgfZ-0003Rh-1h@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 07655b3dee4f by Victor Stinner in branch '3.2':
Issue #11223: skip test_lock_acquire_interruption() on FreeBSD6
http://hg.python.org/cpython/rev/07655b3dee4f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Thu Jun 23 11:59:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Jun 2011 09:59:07 +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: <E1QZggk-0003Wr-Kz@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3f18a03a2a1e by Victor Stinner in branch 'default':
(null merge 3.2 for issue #11223) python 3.3 has already a better fix
http://hg.python.org/cpython/rev/3f18a03a2a1e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Thu Jun 23 14:22:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Jun 2011 12:22:51 +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: <E1QZivp-0006cg-K4@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e5183f16c49d by Victor Stinner in branch '3.2':
Issue #11223: skip also test_rlock_acquire_interruption() on FreeBSD6
http://hg.python.org/cpython/rev/e5183f16c49d

New changeset 54fb77e0762c by Victor Stinner in branch 'default':
(null merge 3.2 for issue #11223) python 3.3 has already a better fix
http://hg.python.org/cpython/rev/54fb77e0762c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Thu Jun 23 14:23:56 2011
From: report at bugs.python.org (jeremybanks)
Date: Thu, 23 Jun 2011 12:23:56 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1308831836.92.0.903815072006.issue6715@psf.upfronthosting.co.za>


Changes by jeremybanks <jeremy at jeremybanks.ca>:


----------
nosy: +jeremybanks

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Jun 23 14:53:21 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Jun 2011 12:53:21 +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: <1308833601.51.0.737258627682.issue2202@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Oh, the bad error message is definitely a bug.  The question is whether we can also add md5-sess support while fixing it.  Sounds like Senthil thinks no, in which case this issue needs to be split into two parts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Thu Jun 23 15:34:49 2011
From: report at bugs.python.org (Chris Withers)
Date: Thu, 23 Jun 2011 13:34:49 +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: <1308836089.68.0.38811398191.issue2202@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

...which is, of course, rather disappointing.
When *would* md5-sess land? 2.7? 3.3?!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Thu Jun 23 15:39:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Jun 2011 13:39:50 +0000
Subject: [issue12383] subprocess.Popen(..., env={}) fails to pass empty env.
In-Reply-To: <1308666962.05.0.419958842608.issue12383@psf.upfronthosting.co.za>
Message-ID: <1308836390.15.0.206777739445.issue12383@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

All Python 3.x buildbots are green again (except FreeBSD 7.2, but the failures are not related to this issue).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12383>
_______________________________________

From report at bugs.python.org  Thu Jun 23 15:41:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Jun 2011 13:41:08 +0000
Subject: [issue11812] transient test_telnetlib failure
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1308836468.96.0.252121358465.issue11812@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/issue11812>
_______________________________________

From report at bugs.python.org  Thu Jun 23 16:15:42 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 23 Jun 2011 14:15:42 +0000
Subject: [issue12356] more argument error improving
In-Reply-To: <1308357931.79.0.860556100237.issue12356@psf.upfronthosting.co.za>
Message-ID: <1308838542.14.0.606356723294.issue12356@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Nick (or anyone else), do you want to look at this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12356>
_______________________________________

From report at bugs.python.org  Thu Jun 23 17:46:40 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Jun 2011 15:46:40 +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: <1308844000.62.0.879560073272.issue2202@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

3.3.

IMO this is in the grey area between feature and bug fix.  I think it is possible to argue that it can be treated as a bug fix, but I think we need opinions from other developers if we want to try to go that route.

The reason I think it can be argued that it can be treated as a bug fix is that (if I understand correctly) there is no difference in the application code.  The only difference is whether or not one can successfully communicate with IIS 6.  That may not be a sufficient argument, but it is an argument :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Thu Jun 23 18:45:14 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 23 Jun 2011 16:45:14 +0000
Subject: [issue10635] Calling subprocess.Popen with preexec_fn=signal.pause
	blocks forever
In-Reply-To: <1291593925.84.0.564814760891.issue10635@psf.upfronthosting.co.za>
Message-ID: <1308847514.87.0.692626532935.issue10635@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10635>
_______________________________________

From report at bugs.python.org  Thu Jun 23 18:50:43 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 23 Jun 2011 16:50:43 +0000
Subject: [issue10636] subprocess module has race	condition with
	SIGCHLD	handlers
In-Reply-To: <1291594796.46.0.99547851622.issue10636@psf.upfronthosting.co.za>
Message-ID: <1308847843.77.0.568814913007.issue10636@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> The right approach is to use sigblock/sigsetmask before creating the
> process, and then again after creating it. Unfortunately, these aren't
> exposed from the signal module.

Since 3.3, pthread_sigmask is exposed so the right approach can now be taken ;-)

Closing as invalid.

----------
nosy: +rosslagerwall
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10636>
_______________________________________

From report at bugs.python.org  Thu Jun 23 18:58:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 23 Jun 2011 16:58:06 +0000
Subject: [issue12372] semaphore errors on AIX 7.1
In-Reply-To: <1308560168.88.0.791994577012.issue12372@psf.upfronthosting.co.za>
Message-ID: <1308848286.49.0.484574523834.issue12372@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Patch attached.
I've used a wildcard so that it won't break when AIX 8 goes out (and it's POSIX).

----------
keywords: +needs review, patch
nosy: +haypo, neologix
stage:  -> patch review
Added file: http://bugs.python.org/file22428/aix_broken_sem.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12372>
_______________________________________

From report at bugs.python.org  Thu Jun 23 21:50:21 2011
From: report at bugs.python.org (Eli Collins)
Date: Thu, 23 Jun 2011 19:50:21 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1308858621.76.0.0183537042142.issue12242@psf.upfronthosting.co.za>


Eli Collins <elic at assurancetechnologies.com> added the comment:

Attached is a patch that implements this enhancement along the lines of what was last discussed. The behavior introduced in the patch is as follows:

*  It adds a stub method named get_compiler_version() to CCompiler, 
   and implementations of that method for the various compilers.
   This method returns the name of the compiler and a version number
   (eg "gcc 4.5.2"), exact format described in docstring 
   of stub method. 

*  It adds two new arguments to the Extension object:
   specific_compile_args, and specific_link_args. 
   These act similarly to extra_compile_args & extra_link_args, 
   except that (if specified) they should contain a list of 
   (regexp string, args) tuples.

   When build_ext runs, it retrieves the version string from
   get_compiler_version() for the current compiler object.
   It matches this against all patterns listed in specific_compile_args.
   The args corresponding to the first pattern that matches
   are appended to extra_compile_args. 
  
   If no pattern matches, extra_compile_args is used unchanged.
   
   If the matched args list contains the magic string "{common_args}",
   any extra_compile_args will be inserted at that location
   instead of appending the matched args, allowing
   for position-dependant arguments.

   specific_link_args is handled in a parallel manner.

*  The Config object has been modified to parse 
   specific_compile_args and specific_link_args 
   in any extension sections.
   Both expect a multiline list of k=v pairs,
   as in the following example:

   [extension=foo]
   ...other settings...
   specific_compile_args = 
         gcc = --optiona --optionb ; some-env-marker = 'value'
         gcc = --optiona  
         .* = --fallbackoption

   These are translated into the format required by Extension()

While this patch works, I have a couple of questions / issues:

1. This patch was made against the hg.python.org/cpython repo.
   There appear to be a number of distutils2 repos floating about
   (hg.python.org/distutils2, and Tarek has some mirrors on bitbucket).
   I'm unclear which one I should be writing this patch against.
   If another repo is more appropriate, I can rebase the patch
   and resubmit. 

2. I'm not sure where I should add documentation about this new behavior.
   I added some documentation to the Extension class itself,
   but that probably isn't the only place it's needed.

3. This feature could probably use some unittests to be added as well.
   I can try my hand at that, but wanted to make sure the design
   was acceptable first.

4. This patch uses ";" to separate k=v pairs from environment markers.
   This is in line with the PEP and the metadata sections.
   However, extra_compile_args's _pop_values() function seems
   to use "--" as it's environment marker separator. 

   This doesn't seem right to me, as "--" is frequently found in options
   strings, and I'd expect it to cause problems.
   If this is a bug in extra_compile_args, 
   I'm happy to create a separate bug and submit a patch.

   However, if there's some reason that "--" should be used,
   I can modify this patch to use "--" as well
   (though that route seems fraught with parsing problems).

Please let me know what more I can do.

----------
keywords: +patch
Added file: http://bugs.python.org/file22429/cpython_issue12242.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12242>
_______________________________________

From report at bugs.python.org  Thu Jun 23 23:25:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Jun 2011 21:25:38 +0000
Subject: [issue12372] semaphore errors on AIX 7.1
In-Reply-To: <1308560168.88.0.791994577012.issue12372@psf.upfronthosting.co.za>
Message-ID: <1308864338.79.0.676975391642.issue12372@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It is the fourth issue for the same problem, other issues:
 - #1106262 (AIX 5, 2005)
 - #1234 (duplicate of #1106262, 2007)
 - #9700 (AIX 6)

The initial issue was related to semaphores and fork() (msg60639). Pass pshared=1 to sem_init() gets around this issue, but introduce new issues (msg60640). In general, locks and fork don't work together: there are still such issues in Python, see for example the issue #6721.

It looks like the behaviour of the semaphore depends on the underlying file system: see msg56228.

Nobody is able to get more information, or maybe nobody wants to dig this issue. It would be better to get the real cause of the issue, and maybe report the issue to the editor of AIX. I don't have access to this AIX, and only few Python developers have access to this OS.

At least, I would like to know if S?bastien Sabl? (the author of the original patch) changed his opinion about this issue since 2007 ;-)

----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12372>
_______________________________________

From report at bugs.python.org  Fri Jun 24 00:25:26 2011
From: report at bugs.python.org (Torsten Landschoff)
Date: Thu, 23 Jun 2011 22:25:26 +0000
Subject: [issue12353] argparse cannot handle empty arguments
In-Reply-To: <1308325206.77.0.428682614263.issue12353@psf.upfronthosting.co.za>
Message-ID: <1308867926.98.0.965693704815.issue12353@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

Here is an updated patch including unit test coverage.

----------
keywords: +patch
nosy: +torsten
Added file: http://bugs.python.org/file22430/issue12353_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12353>
_______________________________________

From report at bugs.python.org  Fri Jun 24 00:56:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Jun 2011 22:56:01 +0000
Subject: [issue12392] pthread_kill() doesn't work on the main thread on
	FreeBSD6
In-Reply-To: <1308869761.72.0.972861691614.issue12392@psf.upfronthosting.co.za>
Message-ID: <1308869761.72.0.972861691614.issue12392@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

pthread_kill() doesn't work on the main thread on FreeBSD6: sending a signal to the main thread does nothing. It works on the main thread just after the creation of the first thread.

PyThread__init_thread() has 3 implementations in Python/thread_pthread.h:
 - call pthread_init()
 - create a dummy thread (no-op) and join it
 - do nothing

pthread_init() doesn't exist on FreeBSD6. If the dummy thread implementation is used, pthread_kill() works directly on the main thread at startup.

----------
messages: 138875
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: pthread_kill() doesn't work on the main thread on FreeBSD6
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12392>
_______________________________________

From report at bugs.python.org  Fri Jun 24 00:58:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Jun 2011 22:58:36 +0000
Subject: [issue12392] pthread_kill() doesn't work on the main thread on
	FreeBSD6
In-Reply-To: <1308869761.72.0.972861691614.issue12392@psf.upfronthosting.co.za>
Message-ID: <1308869916.66.0.0438306068015.issue12392@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Attached patch implements the suggested fix.

----------
keywords: +patch
Added file: http://bugs.python.org/file22431/thread_init_freebsd6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12392>
_______________________________________

From report at bugs.python.org  Fri Jun 24 01:06:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Jun 2011 23:06:07 +0000
Subject: [issue12392] pthread_kill() doesn't work on the main thread on
	FreeBSD6
In-Reply-To: <1308869761.72.0.972861691614.issue12392@psf.upfronthosting.co.za>
Message-ID: <1308870367.06.0.0171125793706.issue12392@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

FreeBSD 7 is not affected by this issue.

To test this issue, call signal.pthread_kill(threading.get_ident(), signal.SIGINT) in an interpreter: it should raise a KeyboardInterrupt. On FreeBSD6, it does nothing. Or run ./python -m test -v test_signal: test_pendings hangs because the test reads 3 bytes from a pipe whereas the pipe is empty. The write end is non blocking, but the read end is blocking.

It would be possible to fix the test to fail instead of blocking: set the read end as non blocking (setUp() does always set the write end as non blocking).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12392>
_______________________________________

From report at bugs.python.org  Fri Jun 24 01:11:12 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jun 2011 23:11:12 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1308870672.44.0.494522322275.issue11812@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

With a bit of searching, HOST == support.HOST == 'localhost'. Looking at the traceback, it is socket that fails, not telnetlib or its test. Hence the clearer title. 

I am still curious what you propose: catch and skip or something else? For Windows, I consider a one-time event like this a routine random glitch to be ignored at least until it repeats ;-).

----------
title: transient test_telnetlib failure -> transient socket failure to connect to 'localhost'
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Fri Jun 24 01:21:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Jun 2011 23:21:47 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1308871307.51.0.44561865963.issue11812@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> With a bit of searching, HOST == support.HOST == 'localhost'.
> Looking at the traceback, it is socket that fails, not telnetlib
> or its test.

I only saw the failure on test_telnetlib, not in other tests using sockets. I think that this issue is specific to test_telnetlib (even not telnetlib). It is maybe a race condition: the code to wait until the server is active is maybe not correct. GeneralTests.setUp() waits until the server has called serv.listen(5). I don't know if the server must be waiting in serv.accept() on Windows (using Cygwin?). Last instruction of GeneralTests.setUp() is a time.sleep(.1): ugly synchronization hack to workaround a race conditon??

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Fri Jun 24 01:33:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Jun 2011 23:33:29 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1308872009.22.0.158421975533.issue11812@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Does the failure occur on other buildbots? If not, it's maybe something specific to this Windows Seven: a local firewall or something like that?

Can we use start 127.0.0.1 instead of "localhost"? I don't know if it would change anything.

Note: the TCP server of test_telnetlib doesn't use SO_REUSEADDR whereas it starts/stops very quickly. We may be something like:

serv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Fri Jun 24 01:38:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Jun 2011 23:38:46 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1308872326.51.0.264580017692.issue11812@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I only saw the failure on test_telnetlib, not in other tests
> using sockets.

Oh, the last failure of the buildbot "x86 Windows7 3.x" is on test_ftplib, not test_telnetlib!

======================================================================
ERROR: testTimeoutConnect (test.test_ftplib.TestTimeouts)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_ftplib.py", line 948, in testTimeoutConnect
    ftp.connect(HOST, timeout=30)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ftplib.py", line 148, in connect
    source_address=self.source_address)
  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.timeout: timed out

======================================================================
ERROR: testTimeoutDefault (test.test_ftplib.TestTimeouts)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_ftplib.py", line 920, in testTimeoutDefault
    ftp = ftplib.FTP("localhost")
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ftplib.py", line 114, in __init__
    self.connect(host)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ftplib.py", line 148, in connect
    source_address=self.source_address)
  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.timeout: timed out

======================================================================
ERROR: testTimeoutDifferentOrder (test.test_ftplib.TestTimeouts)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_ftplib.py", line 955, in testTimeoutDifferentOrder
    ftp.connect(HOST)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ftplib.py", line 148, in connect
    source_address=self.source_address)
  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.timeout: timed out

======================================================================
ERROR: testTimeoutDirectAccess (test.test_ftplib.TestTimeouts)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_ftplib.py", line 963, in testTimeoutDirectAccess
    ftp.connect(HOST)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ftplib.py", line 148, in connect
    source_address=self.source_address)
  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.timeout: timed out

======================================================================
ERROR: testTimeoutNone (test.test_ftplib.TestTimeouts)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_ftplib.py", line 932, in testTimeoutNone
    ftp = ftplib.FTP("localhost", timeout=None)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ftplib.py", line 114, in __init__
    self.connect(host)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ftplib.py", line 148, in connect
    source_address=self.source_address)
  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

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Fri Jun 24 02:06:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jun 2011 00:06:05 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1308873965.84.0.528019447061.issue11812@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Some tests of test_ftplib and test_telnetlib use HOST or directly 'localhost' instead of getting the host from the server socket. About the test_ftplib failures, only the tests using explicitly 'localhost' do fail.

Attached patch reads the name of the server socket instead of using HOST or 'localhost'.

You would like to try it on Linux by changing support.bind_port() function: replace the default host value from HOST to '127.0.0.2'. If you do that, test_ftplib and test_telnetlib fail without my patch, and pass with my patch.

By the way, why do we use 'localhost' instead of '127.0.0.1' for support.HOST? '127.0.0.1' doesn't depend on the DNS configuration of the host (especially its "hosts" file, even Windows has such file).

----------
keywords: +patch
Added file: http://bugs.python.org/file22432/tests_host.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Fri Jun 24 03:01:24 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jun 2011 01:01:24 +0000
Subject: [issue12353] argparse cannot handle empty arguments
In-Reply-To: <1308325206.77.0.428682614263.issue12353@psf.upfronthosting.co.za>
Message-ID: <1308877284.63.0.686789481781.issue12353@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Your unit test isn't consistent with the other unit tests in that set, which makes me suspicious that it isn't testing what we need to test.  Also, there are unit tests for this case further up in the test file (TestEmptyAndSpaceContainingArguments).  I haven't been able to reproduce the bug.

Can you post a short program that reproduces the failure?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12353>
_______________________________________

From report at bugs.python.org  Fri Jun 24 03:10:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jun 2011 01:10:13 +0000
Subject: [issue10206] python program starting with unmatched quote spews
	spaces to stdout
In-Reply-To: <1288123288.86.0.422520379457.issue10206@psf.upfronthosting.co.za>
Message-ID: <1308877813.99.0.197321565323.issue10206@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  I don't know that it is really necessary to cater to the particular failure mode, I was more interested in seeing a unit test that checked the correct behavior: that a syntax error is raised (by capturing the output using the tools in script_helper).  If we do keep the timeout, comments explaining why would be a good idea, because it is completely un-obvious why the test is doing what it is doing...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Fri Jun 24 03:27:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Jun 2011 01:27:52 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <E1QZvBW-0006Xa-KM@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1e89444f4ebc by R David Murray in branch '2.7':
#9921: clarify os.path.join joining algorithm
http://hg.python.org/cpython/rev/1e89444f4ebc

New changeset f5f5b715be7e by R David Murray in branch '3.2':
#9921: clarify os.path.join joining algorithm
http://hg.python.org/cpython/rev/f5f5b715be7e

New changeset b6759568b812 by R David Murray in branch 'default':
merge #9921: clarify os.path.join joining algorithm
http://hg.python.org/cpython/rev/b6759568b812

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Fri Jun 24 03:28:21 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jun 2011 01:28:21 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1308878901.93.0.768927110072.issue9921@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/issue9921>
_______________________________________

From report at bugs.python.org  Fri Jun 24 03:45:14 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jun 2011 01:45:14 +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: <1308879914.73.0.0444781808463.issue11909@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For the most part the patch looks good to me, too.  My one concern is the encoding.  tokenize detects the encoding...is it possible for the doctest fragment to be detected to be some encoding other than utf-8?

----------
nosy: +benjamin.peterson, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11909>
_______________________________________

From report at bugs.python.org  Fri Jun 24 04:44:01 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 24 Jun 2011 02:44:01 +0000
Subject: [issue12356] more argument error improving
In-Reply-To: <1308357931.79.0.860556100237.issue12356@psf.upfronthosting.co.za>
Message-ID: <1308883441.68.0.882666346452.issue12356@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Revised error messages and tests look reasonable and the code seems fine on a visual scan.

+1 from me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12356>
_______________________________________

From report at bugs.python.org  Fri Jun 24 07:58:14 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Jun 2011 05:58:14 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1308895094.46.0.222200476265.issue11812@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Perhaps Michael or Ezio have an idea of whether 'reason' or 'happenstance' is the answer to your questions.

----------
nosy: +ezio.melotti, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Fri Jun 24 08:21:30 2011
From: report at bugs.python.org (Torsten Landschoff)
Date: Fri, 24 Jun 2011 06:21:30 +0000
Subject: [issue12353] argparse cannot handle empty arguments
In-Reply-To: <1308325206.77.0.428682614263.issue12353@psf.upfronthosting.co.za>
Message-ID: <1308896490.66.0.817811680928.issue12353@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

> Your unit test isn't consistent with the other unit tests in that set, which makes me suspicious that it isn't testing what we need to test. 

That is because I did not try to understand the machinery behind the argparse unit tests completely. I did not want to create an extra unit test class just for this one test.

> Also, there are unit tests for this case further up in the test file (TestEmptyAndSpaceContainingArguments).  I haven't been able to reproduce the bug.

Did you run the unit tests from my patch?

> Can you post a short program that reproduces the failure?

Here you go:

from argparse import ArgumentParser
parser = ArgumentParser(fromfile_prefix_chars="@")
parser.parse_args([""])

This gives me

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/python3/lib/python3.3/argparse.py", line 1726, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/opt/python3/lib/python3.3/argparse.py", line 1758, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/opt/python3/lib/python3.3/argparse.py", line 1770, in _parse_known_args
    arg_strings = self._read_args_from_files(arg_strings)
  File "/opt/python3/lib/python3.3/argparse.py", line 2003, in _read_args_from_files
    if arg_string[0] not in self.fromfile_prefix_chars:
IndexError: string index out of range

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12353>
_______________________________________

From report at bugs.python.org  Fri Jun 24 08:27:24 2011
From: report at bugs.python.org (Torsten Landschoff)
Date: Fri, 24 Jun 2011 06:27:24 +0000
Subject: [issue12353] argparse cannot handle empty arguments
In-Reply-To: <1308325206.77.0.428682614263.issue12353@psf.upfronthosting.co.za>
Message-ID: <1308896844.8.0.953109179539.issue12353@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

Here is another possible patch that will catch the problem.

But this enables the fromfile_prefix_chars option for all tests checking empty and space arguments. This way a problem that occurs only without that option might be hidden.

We would need to run those tests with and without fromfile_prefix_chars.

----------
Added file: http://bugs.python.org/file22433/modify_test_empty.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12353>
_______________________________________

From report at bugs.python.org  Fri Jun 24 10:20:33 2011
From: report at bugs.python.org (Stephen Thorne)
Date: Fri, 24 Jun 2011 08:20:33 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1308903633.06.0.304654423619.issue11104@psf.upfronthosting.co.za>


Stephen Thorne <stephen at thorne.id.au> added the comment:

I have 2 patches, with tests, that applies on python2.7 and the python3 series of branches, attached this ticket. I have also got a signed contributor agreement lodged with the PSF.

Can I please have someone either apply my patches or tell me what I need to do in order to change them if they are being rejected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11104>
_______________________________________

From report at bugs.python.org  Fri Jun 24 10:34:46 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 24 Jun 2011 08:34:46 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>
Message-ID: <1308904486.08.0.798159509987.issue12303@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Here's a patch to add the two functions (with docs and tests).

You'll need to run autoreconf before compiling.

----------
assignee:  -> rosslagerwall
keywords: +patch
nosy: +rosslagerwall
stage:  -> patch review
type:  -> feature request
Added file: http://bugs.python.org/file22434/issue12303.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Fri Jun 24 10:40:45 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Fri, 24 Jun 2011 08:40:45 +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: <1308904845.51.0.466556934052.issue11909@psf.upfronthosting.co.za>


Devin Jeanpierre <jeanpierreda at gmail.com> added the comment:

You're right, and good catch. If a doctest starts with a "#coding:XXX" line, this should break.

One option is to replace the call to tokenize.tokenize with a call to tokenize._tokenize and pass 'utf-8' as a parameter. Downside: that's a private and undocumented API. The alternative is to manually add a coding line that specifies UTF-8, so that any coding line in the doctest would be ignored. 

My preferred option would be to add the ability to read unicode to the tokenize API, and then use that. I can file a separate ticket if that sounds good, since it's probably useful to others too.

One other thing to be worried about -- I'm not sure how doctest would treat tests with leading "coding:XXX" lines. I'd hope it ignores them, if it doesn't then this is more complicated and the above stuff wouldn't work.

I'll see if I have the time to play around with this (and add more test cases to the patch, correspondingly) this weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11909>
_______________________________________

From report at bugs.python.org  Fri Jun 24 10:44:49 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 08:44:49 +0000
Subject: [issue12361] Memory Leak in File Logging
In-Reply-To: <1308440220.9.0.536544421463.issue12361@psf.upfronthosting.co.za>
Message-ID: <1308905089.48.0.774851181285.issue12361@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Marked as pending since no further information is available. I will close this issue in two weeks unless more information becomes available; even after this, if you get more information, you can re-open this issue.

Also please note that Python 2.6 is closed for changes other than security-related ones.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12361>
_______________________________________

From report at bugs.python.org  Fri Jun 24 10:53:25 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 08:53:25 +0000
Subject: [issue12393] Packaging should provide support for extensible
	categories
In-Reply-To: <1308905605.65.0.75321405353.issue12393@psf.upfronthosting.co.za>
Message-ID: <1308905605.65.0.75321405353.issue12393@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

Some installation locations are platform-dependent and cannot be categorised into a small but fixed number of categories. This is particularly true for the Windows ecosystem - PowerShell, Office, SharePoint all have specific locations where files need to be installed for interoperability with them.

This can be catered for by a pre-hook for install_data, but some very small core changes are needed:

1. In the install_data constructor, initialise self.categories to an empty dictionary.
2. In install_data.expand_categories, add a  "local_vars.update(self.categories)" after the "local_vars = get_paths()" statement.

Just these small changes are sufficient to allow sufficient control over custom installation locations. For projects that need custom categories, they just need to do the necessary setup in an install_data pre-hook:

def pre_install_data(cmd):
    cmd.categories['customcategory'] = '/path/for/my/custom/category'

I have this working in the pythonv branch, and if the feature request is accepted I can work up a patch including changes to docs, tests etc.

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 138895
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: normal
severity: normal
status: open
title: Packaging should provide support for extensible categories
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12393>
_______________________________________

From report at bugs.python.org  Fri Jun 24 11:14:24 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 09:14:24 +0000
Subject: [issue12394] Packaging should provide better support for executable
	scripts on Windows
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

At present, packaging support for scripts on Windows is the same as for any other system. This is sub-optimal, for the following reasons:

1. Windows doesn't support #! lines to find the correct executable for a script. On a system with multiple Python versions and scripts written for particular versions, support for locating the correct needs to be present.
2. Windows has two types of executables - console applications and GUI applications - and Windows users expect correct usage of either python.exe or pythonw.exe, depending on the individual script being run.

Setuptools (and therefore Distribute) support these requirements by installing a script "demo", on Windows, as "demo.exe" and "demo-script.py" (or "demo-script.pyw"), where demo.exe is a stock Windows executable (either console or GUI) which invokes the appropriate Python executable on the "demo-script.py[w]" file.

Packaging should provide a similar mechanism, which can be implemented very simply by changing the build_scripts command appropriately. It should work like this:

1. When writing a script, the developer simply provides a #!line as normal, but if intended for deployment on Windows, ensures the executable is named as "pythonw" rather than "python". The script should have no extension, as would be for case for a script Linux or OS X.
2. On Windows, the build-scripts command will build the script as it does now - substituting the correct executable for the #! line - but on Windows, instead of writing the script out as e.g. "demo", it will write it as either "demo-script.py" or "demo-script.pyw" (depending on whether the #! line had "pythonw" in it or not), and will also write a stock executable (either console or GUI, depending) with the corresponding name "demo.exe".
3. Since install_scripts just copies files from the build directory, there shouldn't need to be any changes here.

The stock executables can be the same as Distribute uses (setuptools/cli.exe and setuptools/gui.exe), if there is no licensing (or other) issue with having them in Python. If there is such an issue, they can be written from scratch to do the same job (it's just one C file).

I have this working in the pythonv branch, and if this feature request is accepted then I can work up a patch with test and doc changes. (The build_scripts changes are quite straightforward.)

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 138896
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: normal
severity: normal
status: open
title: Packaging should provide better support for executable scripts on Windows
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 11:18:22 2011
From: report at bugs.python.org (Tim Golden)
Date: Fri, 24 Jun 2011 09:18:22 +0000
Subject: [issue12394] Packaging should provide better support for executable
	scripts on Windows
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <4E04565B.6030101@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Are you aware of PEP 397?

http://www.python.org/dev/peps/pep-0397/

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 11:46:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jun 2011 09:46:09 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>
Message-ID: <1308908769.53.0.317699955802.issue12303@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Cool, a patch! "Some" comments.

Why do you wait until the end of PyInit_signal() to set initialized to 1? If this variable is only present to call PyStructSequence_InitType() only once, you can set initialized to 1 directly in the if. Is it possible that PyInit_signal() is called more than once? C modules cannot be unloaded in Python, but I see that the init function of the posixmodule.c has also a static initialized variable.

Doc: The sigwaitinfo()/sigtimedwait() manual page contains interesting infos:

"(If one of the signals in set is already pending for the calling thread,  sigwaitinfo() will return immediately with information about that signal.)"

"If both fields of this structure are specified as  0,  a  poll  is  performed:  sigtimedwait() returns  immediately,  either with information about a signal that was pending for the caller, or with an error if none of the signals in set was pending."

The manpage doesn't tell that the signal handler is not called, should we say it in the Python doc?

Doc: you may add links between pause(), sigwait(), sigwaitinfo() and sigtimedwait() functions. We should maybe reorganise the signal doc to group functions. We need maybe a section for "pending signals" functions, functions to block or wait signals: pause(), pthread_sigmask(), sigpending(), sigwait(), sigwaitinfo(), sigtimedwait(). Another big theme of the signal module is signal handling. We may group functions by these two themes. Well, it is better to reorganize the doc is a second commit ;-)

The timeout is a tuple. Usually, Python uses float for timeout (e.g. see select.select). I suppose that you chose a tuple to keep the precision of the timespec structure. We may accept both types: (sec: int, nanosec: int) or sec: float. It would be nice to have the opinion of our time expect, Alexander Belopolsky.

It is possible to pass a negative timeout: the select() functions accepts or not negative timeout depending on the platform. In Python 3.3, select.select() now always raise an exception if the timeout is negative to have the same behaviour on all platforms. According to the Linux manual page, sigtimedwait() can return EINVAL if the timeout is invalid. We may also always raise an exception if the timeout is negative in sigtimedwait()?

signal_sigwaitinfo() and signal_sigtimedwait() use iterable_to_sigset() whereas this function is only compiled if "#if defined(PYPTHREAD_SIGMASK) || defined(HAVE_SIGWAIT)". You have to fix this test.

According to the manual page, sigwaitinfo() or sigtimedwait() can be interrupted (EINTR) by an unexpected signal (in signal not the signal set): you should call PyErr_CheckSignals(). You should add a test for this case.

Your patch doesn't touch configure nor pyconfig.h.in, only configure.in. Edit configure manually (better to limit the size of the patch) and run autoheader to regenerate pyconfig.h.in (or maybe edit manually pyconfig.h.in).

siginfo_t structure contains more fields, but I don't know if we need all of them. It can be improved later.

sigtimedwait() raises a OSError(EGAIN) on timeout. The behaviour must be documented, or we can choose another behaviour. We may simply return None in case of a timeout, it is just more practical to use than a try/except. For example, threading.Lock.acquire(timeout) simply returns False in case of a timeout. select.select() returns ([], [], []) in case of a timeout, not an exception.

test_sigtimedwait_timeout(): why do you call signal.alarm()? You may also add a test for timeout=0, I suppose that it is a special timeout value.

I will do a deeper review on the second version of your patch :-) Thanks again for the patch. I tried to write it, but I was bored of the siginfo_t fields (too many fields, and I didn't know how to expose them in Python).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Fri Jun 24 12:18:10 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 10:18:10 +0000
Subject: [issue12394] Packaging should provide better support for executable
	scripts on Windows
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308910690.4.0.535723076497.issue12394@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

@Tim: It had gone under my radar, thanks for the link!

I don't know if/when it will be accepted (i.e. whether before 3.3), so my suggestion could be considered as a fallback alternative which works now. If the PEP 397 launcher is available, then of course we should use that.

Of course PEP 397 does not support 'pythonw' in shebang lines, but the "pythonw" I am suggesting here will not appear in the final output script anyway. It's more of a hint to build_scripts indicating the launcher to use. It seems this choice is still required, since from a quick reading of PEP 397, I couldn't see how the user could just type "demo" for an eponymous script in a virtualenv and get the correct launcher (console or GUI).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 12:33:26 2011
From: report at bugs.python.org (Tim Golden)
Date: Fri, 24 Jun 2011 10:33:26 +0000
Subject: [issue12394] Packaging should provide better support for executable
	scripts on Windows
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308911606.03.0.480060438195.issue12394@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

Adding Mark H as the author of PEP 397

----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 12:44:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 10:44:18 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1308912258.24.0.0674656395454.issue11104@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have outstanding comments and questions on the review page (follow the review link on the right of the 3.x patch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11104>
_______________________________________

From report at bugs.python.org  Fri Jun 24 12:46:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 10:46:13 +0000
Subject: [issue12394] Packaging should provide better support for executable
	scripts on Windows
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308912373.03.0.566614446029.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

My GSoC student will work on integrating the scripts generation from setuptools into packaging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 12:50:56 2011
From: report at bugs.python.org (Stephen Thorne)
Date: Fri, 24 Jun 2011 10:50:56 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1308912656.88.0.00272574369968.issue11104@psf.upfronthosting.co.za>


Stephen Thorne <stephen at thorne.id.au> added the comment:

Oh! I didn't see any notification that there was a review done. Thanks, I'll attend to that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11104>
_______________________________________

From report at bugs.python.org  Fri Jun 24 12:51:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 10:51:37 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1308912697.78.0.804709227855.issue12191@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

haypo, you missed this comment from gps on Rietveld:

> As for the _user = user stuff, the reason that is being done is so
> that the original user and or group value can be included in the
> raised exception error message.  That is actually a nice thing to do.
> 
> otherwise, yes, i'd normally just reassign the parameters.
>
> At this point I believe this patch is ready to commit.  I'd reword
> the docstring to make it simpler but that is a minor detail and
> something that is easy to change in a future commit.

I agree the patch is ready.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Fri Jun 24 12:56:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 10:56:29 +0000
Subject: [issue12388] cannot specify recursive extra_files in packaging
	setup.cfg
In-Reply-To: <1308778662.94.0.774064324312.issue12388@psf.upfronthosting.co.za>
Message-ID: <1308912989.9.0.830760421802.issue12388@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1.  We have a function in the util module to handle such extended globs (it?s used by the resources code), so this should not be hard.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12388>
_______________________________________

From report at bugs.python.org  Fri Jun 24 12:57:04 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 10:57:04 +0000
Subject: [issue12394] Packaging should provide better support for executable
	scripts on Windows
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308913024.59.0.097806563424.issue12394@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

?ric, what will be the scope of that integration? Please bear in mind, I have a working solution, so there's no need to cover this part again unless you think there's a problem with my implementation. 

The changes were straightforward, see

https://bitbucket.org/vinay.sajip/pythonv/changeset/d2453f281baf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 12:57:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 10:57:45 +0000
Subject: [issue12393] Packaging should provide support for extensible
	categories
In-Reply-To: <1308905605.65.0.75321405353.issue12393@psf.upfronthosting.co.za>
Message-ID: <1308913065.87.0.657442434106.issue12393@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think this should be part of the setup.cfg specification, not an install_data hook.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12393>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:00:41 2011
From: report at bugs.python.org (sorin)
Date: Fri, 24 Jun 2011 11:00:41 +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: <1308913241.92.0.234501045508.issue11898@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

Can we get more info regarding resolution of this bug. Due to this bug httplib cannot be used anymore to send binary data. This bug breaks other modules, one example being PyAMF (that does communicate only using binary data).

----------
nosy: +sorin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:01:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 11:01:53 +0000
Subject: [issue12394] Packaging should provide better support for executable
	scripts on Windows
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308913313.03.0.248452290669.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

In the setup.cfg files, scripts will now be a mapping of names to callables, like the setuptools scripts and gui_scripts entry points:

scripts =
    sphinx-build = sphinx.build.run

On UNIX, a Python script named sphinx-build will be created, on Windows, a binary sphinx-build.exe will be created.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:09:16 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 11:09:16 +0000
Subject: [issue12393] Packaging should provide support for extensible
	categories
In-Reply-To: <1308905605.65.0.75321405353.issue12393@psf.upfronthosting.co.za>
Message-ID: <1308913756.24.0.110242375744.issue12393@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

@?ric: I agree that some support in setup.cfg would be good, but the problem is that you can't be 100% declarative - sometime the locations can only be determined at runtime. 

I assume you are thinking of something like:

[install_data]
categories = 
    cat1 = path1
    cat2 = path2

In my specific use case, declarative paths will not work in all scenarios - you have to use ctypes to call a Windows API (SHGetKnownFolderPath) to find the specific place to put things.

The two approaches can work together - the categories dictionary can be populated from setup.cfg where this makes sense, and of course for static paths it makes perfect sense. The Windows world is a lot more chaotic than static paths can cater for, unfortunately :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12393>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:14:06 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 11:14:06 +0000
Subject: [issue12394] Packaging should provide better support for executable
	scripts on Windows
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308914046.01.0.340488480974.issue12394@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Does that mean that you can't just put an arbitrary Python script in your application? You have to structure it as a callable?

Of course, I see the applicability of it for the entry_points functionality of setuptools.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:20:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 11:20:35 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1308914435.02.0.359886769633.issue12242@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks!

> This patch was made against the hg.python.org/cpython repo.
This is good.  See http://wiki.python.org/moin/Distutils/Contributing

> I'm not sure where I should add documentation about this new behavior.
At least in Doc/library/packaging.compiler.rst and Doc/packaging/setupcfg.rst, maybe in Doc/install too.

> This feature could probably use some unittests to be added as well.
Yes.  You can see how we use mocking in test_unixccompiler.py or test_util.py to test real-world program output and make sure our code parses it right.

> This doesn't seem right to me, as "--" is frequently found in options
> strings, and I'd expect it to cause problems.  If this is a bug in
> extra_compile_args, I'm happy to create a separate bug and submit a patch.
Please do.  I?ll look into the history to see whether there was a comment about that, but this really looks like a bug.  The separator should be something that can?t be part of options strings, like ?;?.

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12242>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:24:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 11:24:29 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1308914669.9.0.999779339928.issue12386@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It is strange that neither the tests for install_distinfo and resources did not catch this.  I agree about the nonsense of opening in binary mode.

----------
assignee: tarek -> eric.araujo
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:25:05 2011
From: report at bugs.python.org (sorin)
Date: Fri, 24 Jun 2011 11:25: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: <1308914705.99.0.108753687868.issue11898@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

There is another problem that makes the problem even more critical. OS X 10.7 does include Python 2.7.1 as the *default* interpreter.

So we'll need both a fix for the future and an workaround.

BTW, the hack with sys.setdefaultencoding cannot be used if you really send binary data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:25:20 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 24 Jun 2011 11:25:20 +0000
Subject: [issue12223] Datamodel documentation page: 'operator' where 'operand'
	should be
In-Reply-To: <1306834975.07.0.689179229064.issue12223@psf.upfronthosting.co.za>
Message-ID: <1308914720.6.0.170189411502.issue12223@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/issue12223>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:27:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 11:27:27 +0000
Subject: [issue12394] Packaging should provide better support for executable
	scripts on Windows
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308914847.8.0.90272391748.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Does that mean that you can't just put an arbitrary Python script in
> your application?

Arbitrary script files are supported via the resources feature (when the bug you reported is fixed :)  The generation of scripts from callables is a widely-used setuptools feature that will solve a number of problems (Python not on PATH on Windows, unnecessary .py extension on UNIX, such things).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:35:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 11:35:33 +0000
Subject: [issue5572] distutils ignores the LIBS configure env var
In-Reply-To: <1238095013.07.0.627782689433.issue5572@psf.upfronthosting.co.za>
Message-ID: <1308915333.43.0.166918463411.issue5572@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m afraid performance improvements are not bug fixes, which are the only possible changes in distutils now.  This change is however appreciated for packaging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5572>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:41:10 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 11:41:10 +0000
Subject: [issue12395] packaging remove fails under Windows
In-Reply-To: <1308915670.23.0.449812169984.issue12395@psf.upfronthosting.co.za>
Message-ID: <1308915670.23.0.449812169984.issue12395@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

"pysetup3 remove projectX" fails on Windows. The reason is that the RECORD file can't be moved, as it's still open (we're using a generator in list_installed_files). Apart from fixing that, a related annoyance is that you get the 

[Error 32] The process cannot access the file because it is being used by another process

but, of course, it doesn't tell you *which* file it failed on. So the error message needs to say which file(s) couldn't be moved.

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 138917
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: normal
severity: normal
status: open
title: packaging remove fails under Windows
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12395>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:43:21 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 11:43:21 +0000
Subject: [issue12394] Packaging should provide better support for executable
	scripts on Windows
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308915801.19.0.193412135176.issue12394@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Then for Unix at least, how will the installer know which resources need the execute permission turned on? Just by the destination?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:49:49 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 11:49:49 +0000
Subject: [issue12395] packaging remove fails under Windows
In-Reply-To: <1308915670.23.0.449812169984.issue12395@psf.upfronthosting.co.za>
Message-ID: <1308916189.68.0.573645918395.issue12395@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I can confirm that putting a list() around the generator allows the removal to proceed:

diff -r d2453f281baf Lib/packaging/install.py
--- a/Lib/packaging/install.py	Fri Jun 24 10:21:46 2011 +0100
+++ b/Lib/packaging/install.py	Fri Jun 24 12:48:33 2011 +0100
@@ -389,7 +389,10 @@
     dist = get_distribution(project_name, use_egg_info=True, paths=paths)
     if dist is None:
         raise PackagingError('Distribution "%s" not found' % project_name)
-    files = dist.list_installed_files(local=True)
+    # list_installed_files returns a generator, and we need the
+    # RECORD file itself closed so that we can move it - under Windows,
+    # you can't move an opened file
+    files = list(dist.list_installed_files(local=True))
     rmdirs = []
     rmfiles = []
     tmp = tempfile.mkdtemp(prefix=project_name + '-uninstall')


The error message does need fixing, though, for cases where something else has a distribution's files open.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12395>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:49:51 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 11:49:51 +0000
Subject: [issue12395] packaging remove fails under Windows
In-Reply-To: <1308915670.23.0.449812169984.issue12395@psf.upfronthosting.co.za>
Message-ID: <1308916191.0.0.321997794801.issue12395@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I can confirm that putting a list() around the generator allows the removal to proceed:

diff -r d2453f281baf Lib/packaging/install.py
--- a/Lib/packaging/install.py	Fri Jun 24 10:21:46 2011 +0100
+++ b/Lib/packaging/install.py	Fri Jun 24 12:48:33 2011 +0100
@@ -389,7 +389,10 @@
     dist = get_distribution(project_name, use_egg_info=True, paths=paths)
     if dist is None:
         raise PackagingError('Distribution "%s" not found' % project_name)
-    files = dist.list_installed_files(local=True)
+    # list_installed_files returns a generator, and we need the
+    # RECORD file itself closed so that we can move it - under Windows,
+    # you can't move an opened file
+    files = list(dist.list_installed_files(local=True))
     rmdirs = []
     rmfiles = []
     tmp = tempfile.mkdtemp(prefix=project_name + '-uninstall')


The error message does need fixing, though, for cases where something else has a distribution's files open.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12395>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:49:58 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 11:49:58 +0000
Subject: [issue12395] packaging remove fails under Windows
In-Reply-To: <1308915670.23.0.449812169984.issue12395@psf.upfronthosting.co.za>
Message-ID: <1308916198.72.0.275646477065.issue12395@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
Removed message: http://bugs.python.org/msg138920

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12395>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:52:58 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 11:52:58 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1308916378.15.0.294425706079.issue12386@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I suppose it's because I'm writing a script as if it were data? (i.e. to the {scripts} location.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:53:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 11:53:37 +0000
Subject: [issue12394] Packaging should provide better support for executable
	scripts on Windows
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308916417.73.0.545323676942.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The copy function used will preserve rights.  IOW, the +x will be needed in the source.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:54:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 11:54:42 +0000
Subject: [issue12395] packaging remove fails under Windows
In-Reply-To: <1308915670.23.0.449812169984.issue12395@psf.upfronthosting.co.za>
Message-ID: <1308916482.05.0.606918388747.issue12395@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> So the error message needs to say which file(s) couldn't be moved.
Isn?t that a Windows error message which we have no control on?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12395>
_______________________________________

From report at bugs.python.org  Fri Jun 24 13:55:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 11:55:38 +0000
Subject: [issue12296] Minor clarification in devguide
In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>
Message-ID: <1308916538.9.0.475667735166.issue12296@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

What about this: (this obviously does not apply to new classes, functions or arguments)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12296>
_______________________________________

From report at bugs.python.org  Fri Jun 24 14:07:31 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 12:07:31 +0000
Subject: [issue12395] packaging remove fails under Windows
In-Reply-To: <1308915670.23.0.449812169984.issue12395@psf.upfronthosting.co.za>
Message-ID: <1308917251.74.0.587284599526.issue12395@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

We could fix the error message, for example, like this:

--- a/Lib/packaging/install.py	Fri Jun 24 10:21:46 2011 +0100
+++ b/Lib/packaging/install.py	Fri Jun 24 13:06:08 2011 +0100
@@ -412,6 +415,7 @@
                     error = _move_file(file_, tmpfile)
                     if error is not None:
                         success = False
+                        failed_on = file_
                         break
                 finally:
                     if not os.path.isfile(file_):
@@ -425,7 +429,7 @@
 
     if not success:
         logger.info('%r cannot be removed.', project_name)
-        logger.info('Error: %s' % str(error))
+        logger.info('Error: %s: %s' % (error, failed_on))
         return False
 
     logger.info('Removing %r: ', project_name)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12395>
_______________________________________

From report at bugs.python.org  Fri Jun 24 14:08:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 12:08:43 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1308917323.21.0.772626450718.issue10403@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I used "methods and attribute" in io.rst because BufferedIOBase
> included one attribute and several methods.  My terminology may be
> off, but I felt this was the correct replacement of "members."

Nearly :)  See in the first message:
> "Members and methods" should just be "attributes".

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Fri Jun 24 14:10:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 12:10:40 +0000
Subject: [issue12379] build outside source fail in head
In-Reply-To: <1308600053.87.0.881101721168.issue12379@psf.upfronthosting.co.za>
Message-ID: <1308917440.56.0.0188824112235.issue12379@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Out-of-tree configure also fails because of missing .o files.

----------
nosy: +dmalcolm, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12379>
_______________________________________

From report at bugs.python.org  Fri Jun 24 14:12:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 12:12:01 +0000
Subject: [issue12396] Delivery failed
In-Reply-To: <20110624121048.E04DE1CC56@psf.upfronthosting.co.za>
Message-ID: <1308917521.19.0.754185379063.issue12396@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This should go to the meta-tracker.

----------
nosy: +eric.araujo
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12396>
_______________________________________

From report at bugs.python.org  Fri Jun 24 14:14:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 12:14:34 +0000
Subject: [issue12395] packaging remove fails under Windows
In-Reply-To: <1308915670.23.0.449812169984.issue12395@psf.upfronthosting.co.za>
Message-ID: <1308917674.74.0.491536287697.issue12395@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ah, nice, just use %r for the filename.  I?ll commit this improvement in a few days.

Do you want to write a test for the remove error?

----------
assignee: tarek -> eric.araujo
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12395>
_______________________________________

From report at bugs.python.org  Fri Jun 24 14:15:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 12:15:40 +0000
Subject: [issue11933] newer() function in dep_util.py mixes up new vs. old
	files due stat.st_mtime vs stat
In-Reply-To: <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>
Message-ID: <1308917740.37.0.981789188328.issue11933@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks, I?ll commit shortly.

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11933>
_______________________________________

From report at bugs.python.org  Fri Jun 24 14:18:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 12:18:23 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308917903.29.0.256621573161.issue12394@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> eric.araujo
nosy: +higery
stage:  -> needs patch
title: Packaging should provide better support for executable scripts on Windows -> packaging: generate scripts from callable (dotted paths)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 14:18:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 12:18:40 +0000
Subject: [issue4015] Make installed scripts executable on windows
In-Reply-To: <1222949528.24.0.767744507339.issue4015@psf.upfronthosting.co.za>
Message-ID: <1308917920.76.0.254180352468.issue4015@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> packaging: generate scripts from callable (dotted paths)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4015>
_______________________________________

From report at bugs.python.org  Fri Jun 24 14:19:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 12:19:46 +0000
Subject: [issue4015] Make installed scripts executable on windows
In-Reply-To: <1222949528.24.0.767744507339.issue4015@psf.upfronthosting.co.za>
Message-ID: <1308917986.78.0.822603098026.issue4015@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We?re going to follow setuptools? lead and generate platform-appropriate script or binary files from callables.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4015>
_______________________________________

From report at bugs.python.org  Fri Jun 24 14:19:55 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Fri, 24 Jun 2011 12:19:55 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1308917995.41.0.494204888576.issue10403@psf.upfronthosting.co.za>


Adam Woodbeck <adam.woodbeck at gmail.com> added the comment:

I was always under the impression attributes and methods were mutually exclusive.  I've corrected the patch as requested.

----------
Added file: http://bugs.python.org/file22436/issue10403_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Fri Jun 24 14:20:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 12:20:39 +0000
Subject: [issue1004696] translate Windows newlines when installing scripts on
	POSIX
Message-ID: <1308918039.24.0.728563154557.issue1004696@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FTR, We?re going to follow setuptools? lead and generate platform-appropriate script or binary files from callables.

----------
superseder: Scripts need platform-dependent handling -> packaging: generate scripts from callable (dotted paths)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1004696>
_______________________________________

From report at bugs.python.org  Fri Jun 24 14:23:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 12:23:19 +0000
Subject: [issue870479] Scripts need platform-dependent handling
Message-ID: <1308918199.68.0.345371332991.issue870479@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

All right, we?re going to follow setuptools? lead and generate platform-appropriate script or binary files from callables.  See the superseder bug report to follow the work that will be done during this summer?s GSoC.

----------
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> packaging: generate scripts from callable (dotted paths)
versions: +Python 3.3 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue870479>
_______________________________________

From report at bugs.python.org  Fri Jun 24 14:23:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 12:23:54 +0000
Subject: [issue976869] Stripping script extensions with distutils
Message-ID: <1308918234.27.0.309522105946.issue976869@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We?re going to follow setuptools? lead and generate platform-appropriate script or binary files from callables.

----------
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> packaging: generate scripts from callable (dotted paths)
versions: +Python 3.3 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue976869>
_______________________________________

From report at bugs.python.org  Fri Jun 24 14:46:43 2011
From: report at bugs.python.org (Ned Batchelder)
Date: Fri, 24 Jun 2011 12:46:43 +0000
Subject: [issue12397] re match object methods have no docstrings
In-Reply-To: <1308919603.82.0.975273627438.issue12397@psf.upfronthosting.co.za>
Message-ID: <1308919603.82.0.975273627438.issue12397@psf.upfronthosting.co.za>


New submission from Ned Batchelder <ned at nedbatchelder.com>:

If I have a match object in hand, and ask for help on its methods, there is no information:

>>> m = re.match("a", "a")
>>> help(m.group)
Help on built-in function group:

group(...)

>>>

----------
messages: 138937
nosy: nedbat
priority: normal
severity: normal
status: open
title: re match object methods have no docstrings
type: behavior
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/issue12397>
_______________________________________

From report at bugs.python.org  Fri Jun 24 15:09:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 13:09:49 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308920989.91.0.37296567741.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Short review of the superseded bugs.

#870479 ? Scripts need platform-dependent handling
A request to remove .py on POSIX and create a .cmd file on Windows.  The .cmd part was quickly shot down (see bug thread for problems), and the discussion moved to the setuptools generation.  Interesting comment by a Windows user:
> In principle I don't have a problem with the automatic generation of an
> EXE (I assume it generates a shell script with no extension on Unix?)
> but it should be done in such a way that the EXE is version-independent.
> This is necessary to ensure that pure-python packages, when made into
> bdist_wininst installers, continue to be version-independent. (At the
> moment, distutils generates version-dependent bdist_wininst packages
> *only* for C extensions. Setuptools generates version-dependent
> installers all the time, which is a pain).
> 
> This may mean that a reimplementation is required, rather than copying
> the setuptools code.

The bug links to a thread on distutils-sig, where we can find one more issue by Robert Kern:
> In the generated script, please use "if __name__ == '__main__':" to
> block out the executable bits. Currently, multiprocessing does not
> work on Windows when the application is started by a console_script.
> Because Windows does not have a true fork, multiprocessing will start
> up clean Python subprocesses that import the __main__ of the parent
> process.
(http://mail.python.org/pipermail/distutils-sig/2009-February/010981.html)


#976869 ? Stripping script extensions with distutils
A patch by Fred Drake (distutils hacker) to build_scripts to remove the unneeded .py on POSIX.


#1004696 ? translate Windows newlines when installing scripts on POSIX
A request that scripts created with CRLF be installed with LF on POSIX, to make the shebang mechanism work.


#4015 ? Make installed scripts executable on windows

A patch to add a .bat file for each script (the .bat runs the .py).  Contains the first discussion about a launcher for Windows (PEP 397), and issues with .exe files.


So, Tarek and Fred have expressed support for the setuptools generation in a handful of bug reports and emails, and a number of users report they like it.  IIUC, setuptools supports using python vs. pythonw on Windows (console vs. GUI), but is not flexible enough about which Python version to use, and does not support installing into bin vs. sbin on UNIX (see http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard to learn more about /bin, /sbin, /usr/bin and /usr/sbin).  The cli.exe and gui.exe files look like they can be reused, but the install_scripts code will require more work.

Another interesting thread that was linked from one of the reports: http://mail.python.org/pipermail/distutils-sig/2004-July/004071.html

Finally, when the script generation is implemented and documented, care should be taken to add some doc about old-style script files compatibility.  Projects can have valid reasons to use files for Python scripts, and need a way to install them.  Issues about shebang edition (the distutils behavior in build_scripts) and newlines translation (#1004696) will need thought.

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 15:13:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 13:13:29 +0000
Subject: [issue12393] Packaging should provide support for extensible
	categories
In-Reply-To: <1308905605.65.0.75321405353.issue12393@psf.upfronthosting.co.za>
Message-ID: <1308921209.03.0.81211814871.issue12393@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I assume you are thinking of something like:
Yep.

> In my specific use case, declarative paths will not work in all
> scenarios - you have to use ctypes to call a Windows API
> (SHGetKnownFolderPath) to find the specific place to put things.
Ah, too bad.

> The two approaches can work together
Yes.  Let?s implement this in setup.cfg and document how to write a hook to call Windows APIs to get app-specific paths.  See also #7175.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12393>
_______________________________________

From report at bugs.python.org  Fri Jun 24 15:13:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 13:13:45 +0000
Subject: [issue7175] Define a standard location and API for configuration files
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1308921225.33.0.386208068478.issue7175@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also #12393.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Fri Jun 24 15:14:25 2011
From: report at bugs.python.org (Stephen Thorne)
Date: Fri, 24 Jun 2011 13:14:25 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1308921265.93.0.0502156788386.issue11104@psf.upfronthosting.co.za>


Stephen Thorne <stephen at thorne.id.au> added the comment:

This patch is an updated patch that fixes the things noted in the review from eric.araujo.

----------
Added file: http://bugs.python.org/file22437/manifest-respect-3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11104>
_______________________________________

From report at bugs.python.org  Fri Jun 24 15:24:02 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Fri, 24 Jun 2011 13:24:02 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1308921842.04.0.118399482611.issue10403@psf.upfronthosting.co.za>


Changes by Adam Woodbeck <adam.woodbeck at gmail.com>:


Added file: http://bugs.python.org/file22438/issue10403_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Fri Jun 24 15:28:49 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 24 Jun 2011 13:28:49 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>
Message-ID: <1308922129.65.0.335775008549.issue12303@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Thanks for the review.

> Why do you wait until the end of PyInit_signal() to set initialized to 1?
Fixed.

> If this variable is only present ... but I see that the init function of the posixmodule.c has also a static initialized variable.
I simply followed the same format of the posix module.

> "(If one of the signals in set is already pending for the calling thread,  sigwaitinfo() will return immediately with information about that signal.)"
Added.

> "If both fields of this structure are specified as  0,  a  poll  is  performed:  sigtimedwait() returns  immediately,  either with information about a signal that was pending for the caller, or with an error if none of the signals in set was pending."
Added.

> The manpage doesn't tell that the signal handler is not called, should we say it in the Python doc?
Added - let's rather be more explicit.

> Doc: you may add links between pause(), sigwait(), sigwaitinfo() and sigtimedwait() functions.
Added.

> The timeout is a tuple. Usually, Python uses float for timeout (e.g. see select.select). I suppose that you chose a tuple to keep the precision of the timespec structure. We may accept both types: (sec: int, nanosec: int) or sec: float. It would be nice to have the opinion of our time expect, Alexander Belopolsky.
The are some uses of this tuple that were added in #10812 (e.g. futimens) that was reviewed by Alexander.
However, there was a conflict about it at #11457.
I'd say for now, let's keep it as a tuple and if a decision is eventually made as to how to
represent nanosecond timestamps, we can change them all then.

> It is possible to pass a negative timeout
It now raises an exception like select.

> signal_sigwaitinfo() and signal_sigtimedwait() use iterable_to_sigset()
Fixed.

> According to the manual page, sigwaitinfo() or sigtimedwait() can be interrupted (EINTR)
Actually, PyErr_SetFromErrno() does this implicitly. I added a test case anyway.

> Your patch doesn't touch configure nor pyconfig.h.in, only configure.in.
I prefer to keep the generated changes out of the patch. When I commit, I'll run autoreconf.

> siginfo_t structure contains more fields, but I don't know if we need all of them. It can be improved later.
POSIX 2008 specifies:
int           si_signo  Signal number. 
int           si_code   Signal code. 
int           si_errno  If non-zero, an errno value associated with 
                        this signal, as described in <errno.h>. 
pid_t         si_pid    Sending process ID. 
uid_t         si_uid    Real user ID of sending process. 
void         *si_addr   Address of faulting instruction. 
int           si_status Exit value or signal. 
long          si_band   Band event for SIGPOLL. 
union sigval  si_value  Signal value.

So I've left out si_addr (I don't think it's needed), si_band (we don't have SIGPOLL)
and si_value (not sure what it's for or how to represent a union :-)).

> sigtimedwait() raises a OSError(EGAIN) on timeout.
It now returns None.

> test_sigtimedwait_timeout(): why do you call signal.alarm()?
Copy/paste error.

> You may also add a test for timeout=0, I suppose that it is a special timeout value.
Added.

> I will do a deeper review on the second version of your patch :-)
How much more in depth can it get ;-) ?

----------
Added file: http://bugs.python.org/file22439/issue12303_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Fri Jun 24 15:31:07 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 24 Jun 2011 13:31:07 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308922267.0.0.0715130793255.issue12394@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

People working on this should probably also look at how zc.buildout's zc.recipe.egg handles script generation.  It's similar to setuptools in that "console_script" entry points are used, but it binds in the desired Python executable as well.

(If you ran the build with an unversioned Python executable name, that's what you get, but if you use a versioned path, it's retained.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 15:59:04 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 13:59:04 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308920989.91.0.37296567741.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308923941.70863.YahooMailRC@web25801.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Short review of the superseded bugs.
> 
> #870479 ? Scripts  need platform-dependent handling
> A request to remove .py on POSIX and create  a .cmd file on Windows.  The .cmd 
>part was quickly shot down (see bug  thread for problems), and the discussion 
>moved to the setuptools  generation.  Interesting comment by a Windows user:
> > In principle I  don't have a problem with the automatic generation of an
> > EXE (I assume  it generates a shell script with no extension on Unix?)
> > but it should be  done in such a way that the EXE is version-independent.
> > This is  necessary to ensure that pure-python packages, when made into
> >  bdist_wininst installers, continue to be version-independent. (At the
> >  moment, distutils generates version-dependent bdist_wininst packages
> >  *only* for C extensions. Setuptools generates version-dependent
> >  installers all the time, which is a pain).

I don't see how it makes sense to aim for version independence, especially since 
2.x and 3.x can each raise SyntaxErrors when presented with the other's code. 
Isn't explicit better than implicit here?

> > This may mean that a  reimplementation is required, rather than copying
> > the setuptools  code.

There's not much sense in making a simplistic copy, that's for sure.

> The bug links to a thread on distutils-sig, where we can find one  more issue 
>by Robert Kern:
> > In the generated script, please use "if  __name__ == '__main__':" to
> > block out the executable bits. Currently,  multiprocessing does not
> > work on Windows when the application is started  by a console_script.
> > Because Windows does not have a true fork,  multiprocessing will start
> > up clean Python subprocesses that import the  __main__ of the parent
> > process.
> (http://mail.python.org/pipermail/distutils-sig/2009-February/010981.html)
> 

FYI I have a "scriptize" script that generates scripts for entry points, example 
is at https://gist.github.com/1044799 which is Windows-friendly (it doesn't 
refer to "xxx-script.py" in usage messages, for example), and may be of 
interest.

> So, Tarek and Fred  have expressed support for the setuptools generation in a 
>handful of bug reports  and emails, and a number of users report they like it.  
>IIUC, setuptools  supports using python vs. pythonw on Windows (console vs. 
>GUI), but is not  flexible enough about which Python version to use, and does 
>not support  installing into bin vs. sbin on UNIX (see 
>http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard to learn more  about 
>/bin, /sbin, /usr/bin and /usr/sbin).  The cli.exe and gui.exe files  look like 
>they can be reused, but the install_scripts code will require more  work.
> 

For  the /bin, /sbin, /usr/bin or /usr/sbin issue, sure - but doesn't it make 
sense to do the other stuff in build_scripts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 16:00:19 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 14:00:19 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308922267.0.0.0715130793255.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308924013.43096.YahooMailRC@web25807.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Fred L. Drake, Jr. <fdrake at acm.org> added the  comment:

> 
> People working on this should probably also look at how  zc.buildout's 
>zc.recipe.egg handles script generation.  It's similar to  setuptools in that 
>"console_script" entry points are used, but it binds in the  desired Python 
>executable as well.
> 
> (If you ran the build with an  unversioned Python executable name, that's what 
>you get, but if you use a  versioned path, it's  retained.)

And also consider what happens when a script is installed into a virtual env, 
when the virtual env's executable *has* to be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 16:03:00 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jun 2011 14:03:00 +0000
Subject: [issue12353] argparse cannot handle empty arguments
In-Reply-To: <1308325206.77.0.428682614263.issue12353@psf.upfronthosting.co.za>
Message-ID: <1308924180.38.0.101912129933.issue12353@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, I see now.  I misread the original traceback.

Creating a new test case would be the appropriate way to go, given the structure of the argparse test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12353>
_______________________________________

From report at bugs.python.org  Fri Jun 24 16:05:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jun 2011 14:05:34 +0000
Subject: [issue12353] argparse cannot handle empty arguments
In-Reply-To: <1308325206.77.0.428682614263.issue12353@psf.upfronthosting.co.za>
Message-ID: <1308924334.13.0.508549100764.issue12353@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Actually, your original test might be fine.  Let me double check the test implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12353>
_______________________________________

From report at bugs.python.org  Fri Jun 24 16:16:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jun 2011 14:16:25 +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: <1308924985.95.0.24293192739.issue11909@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree that having a unicode API for tokenize seems to make sense, and that would indeed require a separate issue.

That's a good point about doctest not otherwise supporting coding cookies.  Those only really apply to source files.  So no doctest fragments ought to contain coding cookies at the start, so your patch ought to be fine.  But I'm not familiar with the doctest internals, so having some tests to prove everything is fine would be great.

Your code could use the tokenize sniffer to make sure the fragment reads as utf-8 and throw an error otherwise.  But using a unicode interface to tokenize would probably be cleaner, since I suspect it would mimic what doctest does otherwise (ignore coding cookies).  But I don't *know* the latter, so your checking it would be appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11909>
_______________________________________

From report at bugs.python.org  Fri Jun 24 16:28:15 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 14:28:15 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1308925695.52.0.747802588625.issue12291@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


Added file: http://bugs.python.org/file22440/ab1c38ffb8d4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Fri Jun 24 16:36:03 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 14:36:03 +0000
Subject: [issue12393] Packaging should provide support for extensible
	categories
In-Reply-To: <1308921209.03.0.81211814871.issue12393@psf.upfronthosting.co.za>
Message-ID: <1308926162.25268.YahooMailRC@web25803.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Yes.  Let?s implement this in setup.cfg and document how to  write a hook to 
>call Windows APIs to get app-specific paths.  See also  #7175.

When you say "let's", do you mean me, or you? :-) Just so we don't *both* do it 
...

Re. #7175, the discussion is somewhat orthogonal - the other issue ISTM is 
really about where to map appdata.* categories.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12393>
_______________________________________

From report at bugs.python.org  Fri Jun 24 16:37:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Jun 2011 14:37:40 +0000
Subject: [issue12356] more argument error improving
In-Reply-To: <1308357931.79.0.860556100237.issue12356@psf.upfronthosting.co.za>
Message-ID: <E1Qa7Vq-0006Jg-MQ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 52744a5a9260 by Benjamin Peterson in branch 'default':
give the names of missing positional or keyword-only arguments (closes #12356)
http://hg.python.org/cpython/rev/52744a5a9260

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12356>
_______________________________________

From report at bugs.python.org  Fri Jun 24 16:41:25 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 24 Jun 2011 14:41:25 +0000
Subject: [issue6474] Inconsistent TypeError message on function calls with
	wrong number of arguments
In-Reply-To: <1247495805.32.0.528519491274.issue6474@psf.upfronthosting.co.za>
Message-ID: <1308926485.45.0.444662001166.issue6474@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Maybe #12356 then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6474>
_______________________________________

From report at bugs.python.org  Fri Jun 24 17:27:11 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 24 Jun 2011 15:27:11 +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: <1308929231.14.0.393999649275.issue11898@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Sorin, can you please open another report with more details and how some condition in httplib breaks PyAMF. We will see through that it is fixed. Commenting on an invalid closed issue is confusing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Fri Jun 24 17:39:53 2011
From: report at bugs.python.org (sorin)
Date: Fri, 24 Jun 2011 15:39:53 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>


New submission from sorin <sorin.sbarnea at gmail.com>:

It looks that Python 2.7 changes did induce some important bugs into httplib due to to implicit str-unicode encoding/decoding.

One clear example is that PyAMF library doesn't work with Python 2.7 because it is not able to generate binary data POST responses.

Please check http://dev.pyamf.org/ticket/823

(partial trackback, full in above bug)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 937, in endheaders
    self._send_output(message_body)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 795, in _send_output
    msg += message_body

----------
messages: 138953
nosy: sorin
priority: normal
severity: normal
status: open
title: Sending binary data with a POST request in httplib can cause Unicode exceptions
type: crash
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/issue12398>
_______________________________________

From report at bugs.python.org  Fri Jun 24 17:40:23 2011
From: report at bugs.python.org (sorin)
Date: Fri, 24 Jun 2011 15:40:23 +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: <1308930023.84.0.674665648095.issue11898@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

Added as bug http://bugs.python.org/issue12398

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Fri Jun 24 17:49:32 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Fri, 24 Jun 2011 15:49:32 +0000
Subject: [issue10206] python program starting with unmatched quote spews
	spaces to stdout
In-Reply-To: <1288123288.86.0.422520379457.issue10206@psf.upfronthosting.co.za>
Message-ID: <1308930572.67.0.198983818874.issue10206@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

I've attached an alternative test case.

I'm not sure if there is a more robust way to test:
self.assert_('SyntaxError' in err.decode('ascii', 'ignore'))

Due the use of 'SyntaxtError' directly as string. I would prefer something like str(SyntaxtError) (or just the name of the exception
without extra text)

Review is welcome

----------
nosy: +francismb
Added file: http://bugs.python.org/file22441/issue10206.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Fri Jun 24 18:06:00 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 24 Jun 2011 16:06:00 +0000
Subject: [issue12399] make cell var initialization more efficient
In-Reply-To: <1308931560.13.0.00225198817974.issue12399@psf.upfronthosting.co.za>
Message-ID: <1308931560.13.0.00225198817974.issue12399@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

Initializing cell variables currently involves 2 nested loops every function call. This patch makes that process much more efficient by saving information which doesn't change every function call to the code object.

----------
components: Interpreter Core
files: bettercells.patch
keywords: patch
messages: 138956
nosy: benjamin.peterson, ncoghlan
priority: normal
severity: normal
stage: patch review
status: open
title: make cell var initialization more efficient
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file22442/bettercells.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12399>
_______________________________________

From report at bugs.python.org  Fri Jun 24 18:07:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jun 2011 16:07:22 +0000
Subject: [issue10206] python program starting with unmatched quote spews
	spaces to stdout
In-Reply-To: <1288123288.86.0.422520379457.issue10206@psf.upfronthosting.co.za>
Message-ID: <1308931642.19.0.759955232102.issue10206@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think that self.assertRegex(err.decode('ascii', 'ignore'), 'SyntaxError') would be fine.  We are extremely unlikely to change the string representation of the name of SyntaxError or omit it from the error message, so I think this is a reliable test.  If you really want to be paranoid, you could use SyntaxError.__name__ as the argument to assertRegex, but there are a number of other places in the test suite where we hardcode the exception names, so I don't think it is necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Fri Jun 24 18:18:36 2011
From: report at bugs.python.org (Collin Winter)
Date: Fri, 24 Jun 2011 16:18:36 +0000
Subject: [issue5572] distutils ignores the LIBS configure env var
In-Reply-To: <1238095013.07.0.627782689433.issue5572@psf.upfronthosting.co.za>
Message-ID: <1308932316.46.0.6795405988.issue5572@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

I have no interest in forward-porting the patch, closing accordingly. At least there will be a record of this patch for anyone interested in getting a free 10% performance boost for their Python 2.x or 3.[012] systems.

----------
assignee: tarek -> eric.araujo
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5572>
_______________________________________

From report at bugs.python.org  Fri Jun 24 18:20:26 2011
From: report at bugs.python.org (SilentGhost)
Date: Fri, 24 Jun 2011 16:20:26 +0000
Subject: [issue12397] re match object methods have no docstrings
In-Reply-To: <1308919603.82.0.975273627438.issue12397@psf.upfronthosting.co.za>
Message-ID: <1308932426.22.0.758159390787.issue12397@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

2.6 is in security-only mode, if I'm not mistaken.

----------
nosy: +SilentGhost
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12397>
_______________________________________

From report at bugs.python.org  Fri Jun 24 18:21:32 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Fri, 24 Jun 2011 16:21:32 +0000
Subject: [issue10206] python program starting with unmatched quote spews
	spaces to stdout
In-Reply-To: <1288123288.86.0.422520379457.issue10206@psf.upfronthosting.co.za>
Message-ID: <1308932492.27.0.180481127244.issue10206@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Just attaching the review patch

----------
Added file: http://bugs.python.org/file22443/issue10206v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Fri Jun 24 18:30:48 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Fri, 24 Jun 2011 16:30:48 +0000
Subject: [issue10206] python program starting with unmatched quote spews
	spaces to stdout
In-Reply-To: <1308931642.19.0.759955232102.issue10206@psf.upfronthosting.co.za>
Message-ID: <4E04BBED.5030009@email.de>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

On 06/24/2011 06:07 PM, R. David Murray wrote:
> self.assertRegex(err.decode('ascii', 'ignore'), 'SyntaxError')

I understand that's the standard way to check if a given failure 
happened in the command line or there is also a helper for that case 
(maybe something: assert_python_raises('-c', "'", SyntaxError))

Thanks !

Francisco

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Fri Jun 24 18:54:04 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 24 Jun 2011 16:54:04 +0000
Subject: [issue12399] make cell var initialization more efficient
In-Reply-To: <1308931560.13.0.00225198817974.issue12399@psf.upfronthosting.co.za>
Message-ID: <1308934444.31.0.146464704243.issue12399@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/issue12399>
_______________________________________

From report at bugs.python.org  Fri Jun 24 18:57:18 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 24 Jun 2011 16:57:18 +0000
Subject: [issue12372] semaphore errors on AIX 7.1
In-Reply-To: <1308864338.79.0.676975391642.issue12372@psf.upfronthosting.co.za>
Message-ID: <BANLkTim5KBpCC4e47MDxQtem=ji31Gmjbg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Nobody is able to get more information, or maybe nobody wants to dig this issue. It would be better to get the real cause of the issue,

Well, it looks like a libc or kernel bug, and we probably can't do
much about it. Just falling back to mutex + condition variable instead
of POSIX semaphores does the trick, so I'll say just avoid POSIX
semaphores altogether on AIX and we should be fine. People could
report this to their AIX vendor, but they should definitely consider
dropping this terminally broken platform and switch to, let's says,
Linux or BSD...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12372>
_______________________________________

From report at bugs.python.org  Fri Jun 24 18:57:33 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 24 Jun 2011 16:57:33 +0000
Subject: [issue12399] make cell var initialization more efficient
In-Reply-To: <1308931560.13.0.00225198817974.issue12399@psf.upfronthosting.co.za>
Message-ID: <1308934653.55.0.23280835842.issue12399@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Could you possibly post a before/after timing comparison?. Some realistic code... Post the test code too.

And yes, I know that the difference will depend of code, and hardware architecture. But some references are better that not reference at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12399>
_______________________________________

From report at bugs.python.org  Fri Jun 24 19:04:42 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 24 Jun 2011 17:04:42 +0000
Subject: [issue12399] make cell var initialization more efficient
In-Reply-To: <1308934653.55.0.23280835842.issue12399@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=cOkAoe_FbhsKCYhn02VV7ejRyJA@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/6/24 Jes?s Cea Avi?n <report at bugs.python.org>:
>
> Jes?s Cea Avi?n <jcea at jcea.es> added the comment:
>
> Could you possibly post a before/after timing comparison?. Some realistic code... Post the test code too.
>
> And yes, I know that the difference will depend of code, and hardware architecture. But some references are better that not reference at all.

Well, I don't really care whether it's faster or not. It's much nicer
looking now, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12399>
_______________________________________

From report at bugs.python.org  Fri Jun 24 19:16:48 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 24 Jun 2011 17:16:48 +0000
Subject: [issue12393] Packaging should provide support for extensible
	categories
In-Reply-To: <1308905605.65.0.75321405353.issue12393@psf.upfronthosting.co.za>
Message-ID: <1308935808.01.0.615582455334.issue12393@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Basic support for categories now added to install_data:

https://bitbucket.org/vinay.sajip/pythonv/changeset/a4822be62d90

I couldn't see a packaging.util function for matching lines of type "key = value", but if there's one I missed, I can change the implementation to suit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12393>
_______________________________________

From report at bugs.python.org  Fri Jun 24 19:23:46 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 24 Jun 2011 17:23:46 +0000
Subject: [issue12399] make cell var initialization more efficient
In-Reply-To: <1308931560.13.0.00225198817974.issue12399@psf.upfronthosting.co.za>
Message-ID: <1308936226.51.0.288048658356.issue12399@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Then change the issue title :-p.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12399>
_______________________________________

From report at bugs.python.org  Fri Jun 24 19:28:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Jun 2011 17:28:36 +0000
Subject: [issue10206] python program starting with unmatched quote spews
	spaces to stdout
In-Reply-To: <1288123288.86.0.422520379457.issue10206@psf.upfronthosting.co.za>
Message-ID: <E1QaABG-00048z-OG@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2a4764376c51 by R David Murray in branch '3.2':
#10206: add test for previously fixed bug.
http://hg.python.org/cpython/rev/2a4764376c51

New changeset 5ec95f46bac5 by R David Murray in branch 'default':
Merge #10206: add test for previously fixed bug.
http://hg.python.org/cpython/rev/5ec95f46bac5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Fri Jun 24 19:30:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jun 2011 17:30:01 +0000
Subject: [issue10206] python program starting with unmatched quote spews
	spaces to stdout
In-Reply-To: <1288123288.86.0.422520379457.issue10206@psf.upfronthosting.co.za>
Message-ID: <1308936601.1.0.63500344259.issue10206@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks, Petri and Francisco.  Eric, I'm closing this since we now have a minimal test.  If you still want to go back and add more tests based on a deeper understanding of what was broken, feel free to reopen the issue.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Fri Jun 24 19:45:30 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 24 Jun 2011 17:45:30 +0000
Subject: [issue12399] make cell var initialization more efficient
In-Reply-To: <1308931560.13.0.00225198817974.issue12399@psf.upfronthosting.co.za>
Message-ID: <1308937530.84.0.896904135412.issue12399@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The attached highly braindead benchmark reports about a 2% improvement.

----------
Added file: http://bugs.python.org/file22444/x.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12399>
_______________________________________

From report at bugs.python.org  Fri Jun 24 20:05:50 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 24 Jun 2011 18:05:50 +0000
Subject: [issue12392] pthread_kill() doesn't work on the main thread on
	FreeBSD6
In-Reply-To: <1308870367.06.0.0171125793706.issue12392@psf.upfronthosting.co.za>
Message-ID: <BANLkTineg73wSX2_-MyshX-p9FYa6mdC3Q@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

> Attached patch implements the suggested fix.

The patch looks good to me.

> It would be possible to fix the test to fail instead of blocking

I think this issue deserves a specific test, since:
- test_pending tests something completely different
- at the time test_pending gets to run, there's a high chance that
threads have already been created

I've attached a patch spawning a new interpreter to test that.

----------
Added file: http://bugs.python.org/file22445/pthread_kill_main_thread.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12392>
_______________________________________
-------------- next part --------------
diff -r 5ec95f46bac5 Lib/test/test_signal.py
--- a/Lib/test/test_signal.py	Fri Jun 24 13:28:08 2011 -0400
+++ b/Lib/test/test_signal.py	Fri Jun 24 20:01:37 2011 +0200
@@ -295,6 +295,31 @@
 
         self.check_signum(signum1, signum2)
 
+    @unittest.skipUnless(hasattr(signal, 'pthread_kill'),
+                         'need signal.pthread_kill()')
+    def test_pthread_kill_main_thread(self):
+        # Test that a signal can be sent to the main thread with pthread_kill()
+        # before any other thread has been created (see issue #12392).
+        code = """if True:
+            import threading
+            import signal
+            import sys
+
+            def handler(signum, frame):
+                sys.exit(3)
+
+            signal.signal(signal.SIGUSR1, handler)
+            signal.pthread_kill(threading.get_ident(), signal.SIGUSR1)
+            sys.exit(0)
+            """
+
+        with spawn_python('-c', code) as process:
+            stdout, stderr = process.communicate()
+            exitcode = process.wait()
+            if exitcode != 3:
+                raise Exception("Child error (exit code %s): %s" %
+                                (exitcode, stdout))
+
     def setUp(self):
         import fcntl
 

From report at bugs.python.org  Fri Jun 24 20:18:04 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jun 2011 18:18:04 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1308939484.43.0.119394525361.issue12398@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If this worked in 2.6 and fails in 2.7, it would probably be helpful if we can determine what change broke it.  I believe hg has some sort of 'bisect' support that might make this not too onerous to do.  Senthil (or someone) will eventually either figure out the problem or do the bisect, but if you want to speed things along you could do the bisect.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12398>
_______________________________________

From report at bugs.python.org  Fri Jun 24 20:22:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Jun 2011 18:22:47 +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: <1308939767.77.0.362457778243.issue11898@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Soren, this is an issue that claimed a bug, not a bug. The resolution is that the claim appears false because the problem arose from using unicode rather than bytes url. The error message may be confusing, but the error class cannot be changed. Senthil says that he *did* send non-ascii bytes with no problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Fri Jun 24 20:53:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Jun 2011 18:53:29 +0000
Subject: [issue12392] pthread_kill() doesn't work on the main thread on
	FreeBSD6
In-Reply-To: <1308869761.72.0.972861691614.issue12392@psf.upfronthosting.co.za>
Message-ID: <E1QaBVQ-00037s-4t@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 024827a9db64 by Victor Stinner in branch 'default':
Issue #12392: fix thread initialization on FreeBSD 6
http://hg.python.org/cpython/rev/024827a9db64

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12392>
_______________________________________

From report at bugs.python.org  Fri Jun 24 20:53:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jun 2011 18:53:56 +0000
Subject: [issue12392] pthread_kill() doesn't work on the main thread on
	FreeBSD6
In-Reply-To: <1308869761.72.0.972861691614.issue12392@psf.upfronthosting.co.za>
Message-ID: <1308941636.39.0.687326185788.issue12392@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I've attached a patch spawning a new interpreter to test that.

Thanks, I commited your test at the same time of the fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12392>
_______________________________________

From report at bugs.python.org  Fri Jun 24 21:03:57 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 24 Jun 2011 19:03:57 +0000
Subject: [issue12374] Execution model should explain compile vs definition vs
	execution time
In-Reply-To: <1308582911.55.0.701954968644.issue12374@psf.upfronthosting.co.za>
Message-ID: <1308942237.82.0.936550949422.issue12374@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/issue12374>
_______________________________________

From report at bugs.python.org  Fri Jun 24 21:07:26 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Jun 2011 19:07:26 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1308942446.63.0.349353343658.issue12398@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

A crash is a segfault or equivalent.
Python 2.6 only gets security fixes.
PyAMF does not run on Python 3. Hence a problem with PyAMF is no evidence of a problem with 3.x. Separate tests/examples would be needed.

Changes are not bugs unless they introduce a discrepancy between code and doc. Please post a self-contained example that exhibits the behavior that you consider a problem. It should not just be a repeat of #11898. Then quote the section of the docs that says (or suggests) that the behavior should be different from what it is.

The PyAMF site says "PyAMF requires Python 2.4 or newer. Python 3.0 isn?t supported yet." Since 3.0 was deprecated 2 years ago with the release of 3.1, I strongly suspect that the statement was written before 2.7 was released a year ago. Library developers should not make open ended promises like 'or newer' -- certainly not without testing and revising as necessary with each new Python version.

If PyAMF was broken by planned, announced, and documented changed in 2.7, that is too bad, but it is a year too late to change 2.7. Like all new versions, it had public beta and release candidate phases when people could test their packages and make comments.

I believe what David is getting at is finding out for sure whether the change was intended or not.

The quote from the link you provide
  >msg += message_body
appears to be the programming error, already explained in #11898,
where msg is unicode and message_body is bytes with non-ascii bytes.

>>> u'a'+'\xf0'
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf0 in position 0: ordinal not in range(128)
This is exactly the same error message that followed in the link, except that the position of the non-ascii byte. The fix is to not do the above.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12398>
_______________________________________

From report at bugs.python.org  Fri Jun 24 21:07:58 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Jun 2011 19:07:58 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1308942478.13.0.718233716407.issue12398@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> test needed
type: crash -> behavior
versions:  -Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12398>
_______________________________________

From report at bugs.python.org  Fri Jun 24 21:32:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jun 2011 19:32:53 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>
Message-ID: <1308943973.64.0.824776448347.issue12303@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

>> It is possible to pass a negative timeout
> It now raises an exception like select.

Great.

>> According to the manual page, sigwaitinfo() or sigtimedwait() 
>> can be interrupted (EINTR)
> Actually, PyErr_SetFromErrno() does this implicitly. I added a test case anyway.

I would prefer an explicit call to PyErr_CheckSignals(), but if there is a test, it's just fine.

> So I've left out si_addr (I don't think it's needed)
> ... and si_value (not sure what it's for or how to represent a union :-))

I don't think that it means something in Python to have an address or this low-level "value" field. If someone needs them, we would need an use case with an example (to test it!). (So ok to not expose them)

> ... si_band (we don't have SIGPOLL)

What do you mean? signal.SIGPOLL exists in Python 3.3.

>> sigtimedwait() raises a OSError(EGAIN) on timeout.
> It now returns None.

Great.

--

>> I will do a deeper review on the second version of your patch :-)
> How much more in depth can it get ;-) ?

Here you have, issue12303_v2.patch:

 - "PyStructSequence_SET_ITEM(result, 4, PyLong_FromPid(si->si_uid));" looks wrong (we don't need to call PyLong_FromLongLong): si_uid type is uid_t, not pid_t. posix_getuid() simply uses PyLong_FromLong((long)getuid()).

 - sigwaitinfo() doc doesn't mention that the function can be interrupted if an unexpected signal is received. I don't know if it should be mentionned. It is mentionned in the manpage, in the ERRORS section (EINTR).

 - tests: test_sigtimedwait_negative_timeout() doesn't need to use _wait_helper() (which creates a subprocess!). You may also test (-1, 0) and (0, -1) timeouts.

 - test_sigwaitinfo(), test_sigtimedwait_poll(), test_sigwaitinfo_interrupted() are called from a child process. In test_wait(), I chose to write manually to stdout and call os._exit(1) (oh, I forgot an explicit sys.stdout.flush()). I don't know if you can use TestCase methods in a child process (I don't know what is written to stdout, _wait_helper() calls os._exit).

 - you may want to prepare the "What's new in Python 3.3" document (mention the 2 new functions)

 - style: _wait_helper(): you don't have to mark the helper as private (-> wait_helper())

 - style: _fill_siginfo() is already a static function you don't need a "_" prefix

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Fri Jun 24 21:47:36 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Jun 2011 19:47:36 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1308944856.23.0.601291974625.issue12398@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Did things like "u'a'+'\xf0'" work in 2.6- (with implicit latin-1 decoding)? (I do not have 2.6 loaded.)

The doc for seq+seq (concatenation) in the language reference section 5.6. Binary arithmetic operations says that both sequences must be the same type. In the Library manual, 5.6. Sequence Types, the footnote for seq+seq makes no mention of a special exception for (some) mixed unicode/byte concatenations. I think footnote 6 about string+string should both note the exception and its limitation (and if the limitation was changed in 2.7, say so). (In any case, the exception was removed in Py3, so *this* is not a Py3 issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12398>
_______________________________________

From report at bugs.python.org  Fri Jun 24 21:55:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jun 2011 19:55:38 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1308945338.07.0.729077321016.issue11457@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I suggest that rather than using composite time stamps,
> decimal.Decimal is used to represent high-precision time in Python.

Hey, why nobody proposed datetime.datetime objects? Can't we improve the datetime precision to support nanoseconds? I would prefer to have a nice datetime object instead of a integer with an "unknown" reference (epoch). Or does it cost too much (cpu/memory) to create "temporary" datetime objects when the user just want to check for the file mode?

Well, the typical usecase of a file timestamp is to check if a file has been modified (mtime greater than the previous value), or if a file is newer than other one (mtimeA > mtimeB). I don't think that formating the timestamp is the most common usage of os.stat() & friends. float, int tuples and Decimal are all comparable types.

For timestamps arguments (e.g. signal.sigtimedwait, #12303), I would like to be able to pass a tuple (int, int) *or a float*. It is not because the function provides high precision that I need high precision. I bet that most user only need second resolution for signal.sigtimedwait for example.

If you want to pass Decimal: why not, as you want :-) But we have to write a shared function to parse timestamps with a nanosecond resolution (to always accept the same types).

By the way, Windows does also use timestamps with a nanosecond resolution, it's not specific to POSIX! Oh! And Python has a os.stat_float_times(False) function to change globally the behaviour of the stat functions! It remembers other bad ideas like the datetime.accept2dyear, sys.setfilesystemencoding() or sys.setdefaultencoding(). I don't like functions changing globally the behaviour of Python!

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Fri Jun 24 22:36:29 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 24 Jun 2011 20:36:29 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1308945338.07.0.729077321016.issue11457@psf.upfronthosting.co.za>
Message-ID: <4E04F54B.8050206@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Hey, why nobody proposed datetime.datetime objects?

datetime.datetime is extremely bad at representing time stamps.
Don't use broken-down time if you can avoid it.

> By the way, Windows does also use timestamps with a nanosecond
> resolution, it's not specific to POSIX!

Actually, it doesn't. The Windows filetime data type uses units
of 100ns, starting on 1.1.1601.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Fri Jun 24 22:45:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jun 2011 20:45:22 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1308948322.11.0.658062605041.issue11457@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> datetime.datetime is extremely bad at representing time stamps.
> Don't use broken-down time if you can avoid it.

I didn't know that datetime is "extremely bad at representing time stamps", could you explain please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Fri Jun 24 22:45:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jun 2011 20:45:59 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Sporadic issues are difficult to analyze on the buildbots because sometimes a test fails, but when it runs again in verbose mode... it doesn't fail anymore. Typical example:

===============================
[ 99/356/1] test_smtplib
Re-running test test_smtplib in verbose mode
(...)
testTimeoutValue (test.test_smtplib.GeneralTests) ... ok
testBasic (test.test_smtplib.DebuggingServerTests) ... test test_smtplib failed -- multiple errors occurred; run in verbose mode for details
ok
testHELP (test.test_smtplib.DebuggingServerTests) ... ok
testNOOP (test.test_smtplib.DebuggingServerTests) ... ok
testNotImplemented (test.test_smtplib.DebuggingServerTests) ... ok
(...)
----------------------------------------------------------------------
Ran 32 tests in 23.664s

OK
===============================

I propose to always run the tests in verbose mode, write the output into a buffer, but only display the output on failure (or ignore the output on success).

Attached patch simplifies regrtest.py usage: replace 4 verbose levels (no verbose option, -v, -w, -W) by only 2 (no verbose option, -v). Always display the full output in case of an error (as we used -w before): no more "multiple error occured" without output trap, no more "oh, rerunning the test doesn't fail" trap. The -v option works as before (directly write the output in verbose mode).

regrtest is much more verbose than before in case of a failure, but I prefer too much information than no information when I try to debug something. If it is too much verbose by default, I can try to use 3 verbose levels (e.g. don't display the full output if only one test failed).

If the patch is accepted, the devguide should also be patched.

----------
components: Tests
files: regrtest_verbose.patch
keywords: patch
messages: 138981
nosy: ezio.melotti, georg.brandl, haypo, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: regrtest: always run tests in verbose mode, but hide the output on success
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22446/regrtest_verbose.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Fri Jun 24 22:55:39 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Fri, 24 Jun 2011 20:55:39 +0000
Subject: [issue6068] ctypes is not correctly handling bitfields backed by 64
	bit integers on Windows
In-Reply-To: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>
Message-ID: <1308948939.61.0.826083872209.issue6068@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Changing title and type to better reflect issue.

On Windows MSVC build, ctypes is not correctly setting bitfields backed by 64 bit integers if specifying custom width. Simple repro:

from ctypes import *

class X(Structure):
    _fields_ = [("a", c_ulonglong, 16),
                ("b", c_ulonglong, 32),
                ("c", c_ulonglong, 16)]
s = X()
s.b = 1

print(s.b) # this prints 0

Whenever field width goes over 32 bits, setting or getting value of the field in cfield.c will only look at last (<actual size> - 32) bits of the field. So if we have a field of 34 bits, only least significant 2 bits will be operated on. The above repro results in an (<actual size> - 32) = 0 bits so nothing is getting set with the assignement.

This is not caught in unit test package because we have only this in test_bitfields.py:

    def test_ulonglong(self):
        class X(Structure):
            _fields_ = [("a", c_ulonglong, 1),
                        ("b", c_ulonglong, 62),
                        ("c", c_ulonglong, 1)]

        self.assertEqual(sizeof(X), sizeof(c_longlong))
        x = X()
        self.assertEqual((x.a, x.b, x.c), (0, 0, 0))
        x.a, x.b, x.c = 7, 7, 7
        self.assertEqual((x.a, x.b, x.c), (1, 7, 1))

For 62 bit width, we will actually operate on last 30 bits but this test passes as 7 fits in those bits. If we would actually try to set it to 0x3FFFFFFFFFFFFFFF, result will be different than expected (0x3FFFFFFF).

I will look into extending UT package with some tests that set full range of bits and check if they are actually being set correctly.

This issue reproes with latest bits but only on Windows. Root cause seems to be BIT_MASK macro in cfield.c which is ifdef-ed to something different on Windows. I patched on my machine by removing the special treatment:

@@ -429,12 +429,7 @@
 #define LOW_BIT(x)  ((x) & 0xFFFF)
 #define NUM_BITS(x) ((x) >> 16)
 
-/* This seems nore a compiler issue than a Windows/non-Windows one */
-#ifdef MS_WIN32
-#  define BIT_MASK(size) ((1 << NUM_BITS(size))-1)
-#else
-#  define BIT_MASK(size) ((1LL << NUM_BITS(size))-1)
-#endif
+#define BIT_MASK(size) ((1LL << NUM_BITS(size))-1)
 
 /* This macro CHANGES the first parameter IN PLACE. For proper sign handling,
    we must first shift left, then right.



Unittests still pass with this in place and now fields are handled correctly though I don't know why this was put in in the first place. Looking at file history it seems it was there from the start (from 2006). Could it be that it was addressing some MSVC bug which got fixed in the meantime? Things seem to be building and working fine now when using 1LL for shift.

Also related to this I have doubts about the SWAP_8 macro which is similarly changed for MSVC, also in cfield.c.

I am only able to build 32 bit version so I can't say whether this was put in place due to some x64 issue, maybe someone can check behavior on x64 build. If that's the case, maybe #ifdef should take that into account.

----------
nosy: +vladris
title: support read/write c_ulonglong type bitfield structures -> ctypes is not correctly handling bitfields backed by 64 bit integers on Windows
type: feature request -> behavior
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6068>
_______________________________________

From report at bugs.python.org  Fri Jun 24 22:55:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 20:55:46 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308948946.81.0.657051408635.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

[Vinay]
> I don't see how it makes sense to aim for version independence,
> especially since 2.x and 3.x can each raise SyntaxErrors when
> presented with the other's code.
Version independence always means version independence in the same major line of development (i.e. X number in X.Y.Z), or to put it another way, version independence among the versions listed as supported in the Trove classifiers.

> For  the /bin, /sbin, /usr/bin or /usr/sbin issue, sure - but doesn't
> it make sense to do the other stuff in build_scripts?
Of course.  As much as possible should be done by build_scripts, and what?s installation-specific is left to install_scripts.

Fred: Thanks for the pointer!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jun 24 22:58:33 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 24 Jun 2011 20:58:33 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1308948322.11.0.658062605041.issue11457@psf.upfronthosting.co.za>
Message-ID: <4E04FA77.1020005@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I didn't know that datetime is "extremely bad at representing time
> stamps", could you explain please?

- there is no easy way to convert it into "seconds since the epoch"
- any broken-down time has issues of time stamp ordering in the
  duplicate hour of switching from DST to normal time
- time zone support is flaky-to-nonexistent in the datetime module

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Fri Jun 24 23:03:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 21:03:10 +0000
Subject: [issue12354] packaging.pypi.simple docs use both client and crawler
	variable, which might be confusing
In-Reply-To: <1308334574.8.0.60329566716.issue12354@psf.upfronthosting.co.za>
Message-ID: <1308949390.73.0.672121628675.issue12354@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Doc update in 8de5fe3b1696

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12354>
_______________________________________

From report at bugs.python.org  Fri Jun 24 23:16:38 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 24 Jun 2011 21:16:38 +0000
Subject: [issue9642] #ifdef and mbcs: don't check
	for	defined(HAVE_USABLE_WCHAR_T)
In-Reply-To: <1282219348.43.0.267719038373.issue9642@psf.upfronthosting.co.za>
Message-ID: <1308950198.01.0.210691727685.issue9642@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

How do the two patches relate?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9642>
_______________________________________

From report at bugs.python.org  Fri Jun 24 23:21:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jun 2011 21:21:51 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1308950511.74.0.296984998866.issue11457@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> there is no easy way to convert it into "seconds since the epoch"

Ah yes, it remembers me that Alexander rejected my .totimestamp() patch (#2736) because he considers that "Converting datetime values to float is easy":

(dt - datetime(1970, 1, 1)) / timedelta(seconds=1)

I still think that this formula is *not* trivial, and must be a builtin method. For example, the formula is different if your datetime object if an aware instance:

(dt - datetime(1970, 1, 1, tzinfo=timezone.utc)) / timedelta(seconds=1)

When do you need to convert file timestamps to epoch? If we use datetime in os.stat output, we should also accept it as input (e.g. for os.utime).

> any broken-down time has issues of time stamp ordering in
> the duplicate hour of switching from DST to normal time

I understand that it is an issue of the datetime module. Can it be solved, or is there a design issue in the module?

> time zone support is flaky-to-nonexistent in the datetime module

Python 3.3 has now a builtin implementation of fixed timezones, but yes, there are still things to be improved (e.g. support timezone names like "CET").

--

I don't have a strong opinion on this issue, I just wanted to know why datetime cannot be used for this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Fri Jun 24 23:39:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jun 2011 21:39:33 +0000
Subject: [issue9642] #ifdef and mbcs: don't check
	for	defined(HAVE_USABLE_WCHAR_T)
In-Reply-To: <1282219348.43.0.267719038373.issue9642@psf.upfronthosting.co.za>
Message-ID: <1308951573.5.0.664291411482.issue9642@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file18577/ifdef_mbcs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9642>
_______________________________________

From report at bugs.python.org  Fri Jun 24 23:41:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Jun 2011 21:41:19 +0000
Subject: [issue6068] ctypes is not correctly handling bitfields backed by 64
	bit integers on Windows
In-Reply-To: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>
Message-ID: <1308951679.29.0.422632520809.issue6068@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Vlad, thanks for delving into this. Your two header changes are contradictory. If this is a feature request, then it is 3.3 only. If this is a behavior (bug) issue, then 3.2 should be included ;-). 'higstar's second comment indicates 'feature', but I am not sure what 'integer field means in this context'. I am guessing that UT = 'unittest'

Higstar, I see buried in your 3rd message the reference to Windows and 2.6. Please specify OS and version in initial messages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6068>
_______________________________________

From report at bugs.python.org  Fri Jun 24 23:42:00 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jun 2011 21:42:00 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1308951720.3.0.622136296009.issue12398@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Many applications and libraries say "Python X.Y or newer", and it is one of the strengths of Python that this will often be true.  That's what our backward compatibility policy is about, and that's why the fact that it isn't true for 2.x->3.x is such a big deal.  As far as I can see there was no deprecation involved here, so "announced" is not a factor, I think.  We won't be sure until we know what changed.

All that said, it is quite possible (even likely, given #11898) that the pyamf code contains a bug and only worked by accident, and is now failing because some other bug in Python was fixed.  Again, we won't know until we have a complete diagnosis of the cause of the change in behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12398>
_______________________________________

From report at bugs.python.org  Fri Jun 24 23:42:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jun 2011 21:42:15 +0000
Subject: [issue9642] #ifdef and mbcs: don't check
	for	defined(HAVE_USABLE_WCHAR_T)
In-Reply-To: <1282219348.43.0.267719038373.issue9642@psf.upfronthosting.co.za>
Message-ID: <1308951735.38.0.367630372376.issue9642@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> How do the two patches relate?

Oh, I forgot to remove my first patch which was wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9642>
_______________________________________

From report at bugs.python.org  Fri Jun 24 23:46:23 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Fri, 24 Jun 2011 21:46:23 +0000
Subject: [issue6068] ctypes is not correctly handling bitfields backed by 64
	bit integers on Windows
In-Reply-To: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>
Message-ID: <1308951983.0.0.581112165809.issue6068@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Terry, I am kind of new to this so I might not have marked header correctly. Please feel free to fix it.

This is 100% bug not feature request. Initial message was confusing because highstar thought Python has such bitfields as readonly and was asking for a feature to make them read-write. That is not the case, behavior is caused by a bug. By UT I mean unittest.

I reproed this on 64bit Windows 7 on latest sources with x32 build (as I said, I don't have x64 build).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6068>
_______________________________________

From report at bugs.python.org  Fri Jun 24 23:49:26 2011
From: report at bugs.python.org (Chris Withers)
Date: Fri, 24 Jun 2011 21:49:26 +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: <1308952166.7.0.579448933986.issue2202@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Who with and where does the argument need to be had?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Fri Jun 24 23:57:56 2011
From: report at bugs.python.org (Henry Precheur)
Date: Fri, 24 Jun 2011 21:57:56 +0000
Subject: [issue12401] unset PYTHON* environment variables when running tests
In-Reply-To: <1308952676.91.0.708236346954.issue12401@psf.upfronthosting.co.za>
Message-ID: <1308952676.91.0.708236346954.issue12401@psf.upfronthosting.co.za>


New submission from Henry Precheur <henry at precheur.org>:

"make test" calls Python with the -E option which ignore the PYTHON*
environment variables, but Python sub-processes aren't necessarily called with the -E options. For example test_displayhook_unencodable in test_cmd_line. This created problems with my own PYTHONSTARTUP script.

I see 2 solutions to this problems:

1. Fix the tests that might be affected by such problems, by adding the -E option everywhere needed.
2. Fix the Makefile and unset all the PYTHON* environment variables in it.

I think that solution #2 is better. Fixing the tests can be done today, but the authors of future tests might not be aware of this issue. By fixing the Makefile we prevent this problem to occur again in the future.

----------
components: Tests
messages: 138993
nosy: henry.precheur
priority: normal
severity: normal
status: open
title: unset PYTHON* environment variables when running tests
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12401>
_______________________________________

From report at bugs.python.org  Fri Jun 24 23:59:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jun 2011 21:59:38 +0000
Subject: [issue12381] refactor slice checks made by methods that take "slice
	like" arguments
In-Reply-To: <1308628637.29.0.156287318778.issue12381@psf.upfronthosting.co.za>
Message-ID: <1308952778.65.0.881344406785.issue12381@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that both of these have been fixed in default, so I'm repurposing this issue for the refactoring I suggested.  However, since I can't find an existing issue for the bytearray fix, maybe somebody already did it and I didn't notice.

----------
title: bytearray methods count, find, index don't support None as in slice notation -> refactor slice checks made by methods that take "slice like" arguments
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12381>
_______________________________________

From report at bugs.python.org  Sat Jun 25 00:00:34 2011
From: report at bugs.python.org (Per Cederqvist)
Date: Fri, 24 Jun 2011 22:00:34 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308952834.34.0.615813451292.issue12394@psf.upfronthosting.co.za>


Changes by Per Cederqvist <ceder at lysator.liu.se>:


----------
nosy: +ceder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Sat Jun 25 00:13:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jun 2011 22:13:58 +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: <1308953638.7.0.169302997022.issue2202@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  How about python-committers?  I would suggest python-dev, but that feels like invoking the dragon :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Sat Jun 25 00:16:05 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Jun 2011 22:16:05 +0000
Subject: [issue6068] ctypes is not correctly handling bitfields backed by 64
	bit integers on Windows
In-Reply-To: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>
Message-ID: <1308953765.68.0.812406019375.issue6068@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6068>
_______________________________________

From report at bugs.python.org  Sat Jun 25 00:32:47 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Fri, 24 Jun 2011 22:32:47 +0000
Subject: [issue6068] ctypes is not correctly handling bitfields backed by 64
	bit integers on Windows
In-Reply-To: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>
Message-ID: <1308954767.57.0.284529524709.issue6068@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Attached is addition to unittests which repro the issue. They will currently pass on Linux but fail on Windows.

----------
keywords: +patch
Added file: http://bugs.python.org/file22447/issue6068_unittest.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6068>
_______________________________________

From report at bugs.python.org  Sat Jun 25 00:37:40 2011
From: report at bugs.python.org (higstar)
Date: Fri, 24 Jun 2011 22:37:40 +0000
Subject: [issue6068] ctypes is not correctly handling bitfields backed by 64
	bit integers on Windows
In-Reply-To: <1308954767.57.0.284529524709.issue6068@psf.upfronthosting.co.za>
Message-ID: <BANLkTikVYU7csATG=5B8ULHVJUm7DTkkCQ@mail.gmail.com>


higstar <adrian at higstar.com> added the comment:

Issue was originally found on do sp2 on Python 2.6.
Thanks Vlad, this rendered ctypes useless for my purposes, had to mask and
shift myself.
On Jun 25, 2011 8:32 AM, "Vlad Riscutia" <report at bugs.python.org> wrote:
>
> Vlad Riscutia <riscutiavlad at gmail.com> added the comment:
>
> Attached is addition to unittests which repro the issue. They will
currently pass on Linux but fail on Windows.
>
> ----------
> keywords: +patch
> Added file: http://bugs.python.org/file22447/issue6068_unittest.diff
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6068>
> _______________________________________

----------
Added file: http://bugs.python.org/file22448/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6068>
_______________________________________
-------------- next part --------------
<p>Issue was originally found on do sp2 on Python 2.6.<br>
Thanks Vlad, this rendered ctypes useless for my purposes, had to mask and shift myself.</p>
<div class="gmail_quote">On Jun 25, 2011 8:32 AM, &quot;Vlad Riscutia&quot; &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br type="attribution">&gt; <br>&gt; Vlad Riscutia &lt;<a href="mailto:riscutiavlad at gmail.com">riscutiavlad at gmail.com</a>&gt; added the comment:<br>
&gt; <br>&gt; Attached is addition to unittests which repro the issue. They will currently pass on Linux but fail on Windows.<br>&gt; <br>&gt; ----------<br>&gt; keywords: +patch<br>&gt; Added file: <a href="http://bugs.python.org/file22447/issue6068_unittest.diff">http://bugs.python.org/file22447/issue6068_unittest.diff</a><br>
&gt; <br>&gt; _______________________________________<br>&gt; Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&gt; &lt;<a href="http://bugs.python.org/issue6068">http://bugs.python.org/issue6068</a>&gt;<br>
&gt; _______________________________________<br></div>

From report at bugs.python.org  Sat Jun 25 00:45:07 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 24 Jun 2011 22:45:07 +0000
Subject: [issue12402] Overriding code.InteractiveConsole.write does not work
In-Reply-To: <1308955507.7.0.876307843842.issue12402@psf.upfronthosting.co.za>
Message-ID: <1308955507.7.0.876307843842.issue12402@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

Consider the following code:
    import code

    class Console(code.InteractiveConsole):
        def write(self, data):
            print("DATA: {0}".format(data))

    c = Console()
    c.interact()

Then enter "1" at the prompt. The output will be 1 (and not DATA: 1).
If you create an error (such as 1/0), then the error lines will be prefixed by DATA.

----------
components: Library (Lib)
messages: 138998
nosy: tebeka
priority: normal
severity: normal
status: open
title: Overriding code.InteractiveConsole.write does not work
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12402>
_______________________________________

From report at bugs.python.org  Sat Jun 25 00:55:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jun 2011 22:55:13 +0000
Subject: [issue12255] A few changes to .*ignore
In-Reply-To: <1307119345.93.0.971452096543.issue12255@psf.upfronthosting.co.za>
Message-ID: <1308956113.55.0.502428890665.issue12255@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Your experiments with .hgignore and your thoughts about server vs. clone .hgignore give me the impression of a misunderstanding of how it works.

To clarify: The repo .hgignore file is a repo-specific listing of patterns to ignore.  As such, it needs to be shared, i.e. put under version control.

The ignore files (the repo .hgignore and optional files configured in ~/.hgrc or $SOMECLONE/.hg/hgrc) are consulted only for some commands:

- hg status (ignored files are not considered unknown)
- hg add . (a recursive add does not consider ignored files)
- hg addremove (etc.)

This explains why putting .hgignore in the .hgignore file cannot possibly work.

If *.rej and *.orig are ignored, they don?t show up in ?hg status?, and are not added with ?hg add somedir?.  My point is that this behavior is not useful: it does not protect from anything (who adds directories when merging changesets?  also, who does not run status and diff before commit?  they should), and does not help us check whether we?ve properly merged all files.  I prefer to see the *.rej files in hg status output, check them and delete them.

So, can I commit?  I?m willing to update the devguide and reply to possibly angry python-dev feedback with an explanation of how to ignore those files on a per-user or per-clone basis.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12255>
_______________________________________

From report at bugs.python.org  Sat Jun 25 01:00:28 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 24 Jun 2011 23:00:28 +0000
Subject: [issue12401] unset PYTHON* environment variables when running tests
In-Reply-To: <1308952676.91.0.708236346954.issue12401@psf.upfronthosting.co.za>
Message-ID: <1308956428.12.0.897835455217.issue12401@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/issue12401>
_______________________________________

From report at bugs.python.org  Sat Jun 25 01:15:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jun 2011 23:15:53 +0000
Subject: [issue12402] Overriding code.InteractiveConsole.write does not work
In-Reply-To: <1308955507.7.0.876307843842.issue12402@psf.upfronthosting.co.za>
Message-ID: <1308957353.38.0.0491443804841.issue12402@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That's correct.  The write method is for writing to stderr, and by implication is called only for errors.  Not, I think, the most obvious name that could have been chosen for the method, but it does seem to be doing what it is documented to do in your example.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12402>
_______________________________________

From report at bugs.python.org  Sat Jun 25 01:23:03 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 24 Jun 2011 23:23:03 +0000
Subject: [issue12141] sysconfig.get_config_vars('srcdir') fails in specific
	cases
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1308957783.39.0.957061670875.issue12141@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Are the patches good to go?  And would you like me to apply them?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Sat Jun 25 01:30:58 2011
From: report at bugs.python.org (Stephen Thorne)
Date: Fri, 24 Jun 2011 23:30:58 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1308958258.28.0.160741724497.issue11104@psf.upfronthosting.co.za>


Stephen Thorne <stephen at thorne.id.au> added the comment:

Updated the patch to address the 'why not use .strip()' question. I used .rstrip('\r\n') on the basis that filenames may have leading or trailing spaces, and if you need that, you need to be able to specify that in a MANIFEST, but it is perfectly logical to disallow them, so here's a patch that doesn't support them.

It also reduces the line count by 2 because I'm composing the 'comment' and 'blank line' cases.

----------
Added file: http://bugs.python.org/file22449/manifest-respect-3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11104>
_______________________________________

From report at bugs.python.org  Sat Jun 25 01:53:10 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 24 Jun 2011 23:53:10 +0000
Subject: [issue12402] Overriding code.InteractiveConsole.write does not work
In-Reply-To: <1308955507.7.0.876307843842.issue12402@psf.upfronthosting.co.za>
Message-ID: <1308959590.1.0.353241805384.issue12402@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

I'm trying to read/write data from a socket. Does this mean I need to roll up my own Interpreter? (e.g. no way to override writing to stdout?)

Since this is the expected behaviour, will close this one.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12402>
_______________________________________

From report at bugs.python.org  Sat Jun 25 01:55:44 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 24 Jun 2011 23:55:44 +0000
Subject: [issue12403] Allow overriding of writing to stdout in
	code.InteractiveConsole
In-Reply-To: <1308959744.93.0.261089879651.issue12403@psf.upfronthosting.co.za>
Message-ID: <1308959744.93.0.261089879651.issue12403@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

Currently, code.InteractiveConsole lets your override "write" which is the error stream. Allow overriding of "normal" (stdout) writing as well.
This will enable to spawn interpreters into custom stdin/stdout.

See twisted.manhole for example, very useful.

----------
messages: 139004
nosy: tebeka
priority: normal
severity: normal
status: open
title: Allow overriding of writing to stdout in code.InteractiveConsole
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12403>
_______________________________________

From report at bugs.python.org  Sat Jun 25 02:05:36 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jun 2011 00:05:36 +0000
Subject: [issue12374] Execution model should explain compile vs definition vs
	execution time
In-Reply-To: <1308582911.55.0.701954968644.issue12374@psf.upfronthosting.co.za>
Message-ID: <1308960336.4.0.652912126837.issue12374@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I presume we are discussing Chapter 4. Execution model. I do not see any mention there of the difference between function definition and body execution time. The section of def statements (7.6) has this: "The function definition does not execute the function body; this gets executed only when the function is called. [3]". This is true for lambda expressions also, but nothing is said there. This may contribute to people expecting name resolution of non-parameters in lambda bodies to happen at lambda expression == function definition time rather than later at function call time (what Nick called function execution time).

I think 4.1. Naming and binding should be slightly expanded and renamed 4.1. Name binding and resolution. People need to understand both how and when associations are made and when they are used (as well as what scopes are used). Not understanding this results in the perennial confusion about params with defaults and free names in lambda expressions.

In function headers, param = expr creates a binding when the header is executed, which is when the function object is created. It is stored in the function object. It may optionally be used when the function is called.

In lambda bodies such as in lambda x: x + i, there is no binding of i so i must be bound in a surrounding context either before the function is defined or before the function is called, depending on the surrounding contex, and used when the function is called.

These two facts are somehow not clear enough at present. In any case, my point is the the 'when' part of name binding and use is related to the when of execution.

The relevance of compilation time is more subtle. It is when module, statement, and function code objects are created, including by compile(). If code objects (and compile) are part of the language, then so is compile time. The existence of both interactive statement execution and delayed module execution also has implications for how Python works and how it can and cannot be modified. I am not sure how much to say, though.

Part of the execution model of Python is that, leaving aside i/o, the effect of executing statements is to change user visible name and slot bindings. There are essentially no declarations for changing invisible compiler/interpreter settings.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12374>
_______________________________________

From report at bugs.python.org  Sat Jun 25 02:17:21 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 25 Jun 2011 00:17:21 +0000
Subject: [issue12399] simplify cell var initialization by storing constant
	data on the code object
In-Reply-To: <1308931560.13.0.00225198817974.issue12399@psf.upfronthosting.co.za>
Message-ID: <1308961041.69.0.828010572738.issue12399@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Reviewed. General concept looks sound, just suggested a few tweaks around the edges.

And issue title updated appropriately :)

----------
title: make cell var initialization more efficient -> simplify cell var initialization by storing constant data on the code object

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12399>
_______________________________________

From report at bugs.python.org  Sat Jun 25 02:22:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jun 2011 00:22:50 +0000
Subject: [issue12376] unittest.TextTestResult.__init__ breaks under complex
	__mro__
In-Reply-To: <1308591554.84.0.206840920137.issue12376@psf.upfronthosting.co.za>
Message-ID: <1308961370.29.0.360180271022.issue12376@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Running your code with 2.7.2 gives:
Traceback (most recent call last):
  File "C:\Programs\Python27\misc\tem.py", line 41, in <module>
    unittest.main(testRunner=runner)
  File "C:\Programs\Python27\lib\unittest\main.py", line 95, in __init__
    self.runTests()
  File "C:\Programs\Python27\lib\unittest\main.py", line 229, in runTests
    self.result = testRunner.run(self.test)
  File "C:\Programs\Python27\lib\unittest\runner.py", line 142, in run
    result = self._makeResult()
  File "C:\Programs\Python27\lib\unittest\runner.py", line 138, in _makeResult
    return self.resultclass(self.stream, self.descriptions, self.verbosity)
  File "C:\Programs\Python27\lib\unittest\runner.py", line 37, in __init__
    super(TextTestResult, self).__init__()
TypeError: __init__() takes exactly 4 arguments (1 given)

Nothing 'explodes', just a normal exception due to what I believe is a programming error on your part that has nothing to do with unittest. The doc for super says
"The second use case is to support cooperative multiple inheritance in a dynamic execution environment. This use case is unique to Python and is not found in statically compiled languages or languages that only support single inheritance. This makes it possible to implement ?diamond diagrams? where multiple base classes implement the same method. Good design dictates that this method have the same calling signature in every case (because the order of calls is determined at runtime, because that order adapts to changes in the class hierarchy, and because that order can include sibling classes that are unknown prior to runtime).""

The various __init__ methods, as you know, have different and incompatible calling signatures, hence the exception. I believe this should be closed as invalid. Raymond, as super expert, do I have this right?

----------
nosy: +rhettinger, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12376>
_______________________________________

From report at bugs.python.org  Sat Jun 25 02:26:06 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jun 2011 00:26:06 +0000
Subject: [issue12397] re match object methods have no docstrings
In-Reply-To: <1308919603.82.0.975273627438.issue12397@psf.upfronthosting.co.za>
Message-ID: <1308961566.67.0.512240831113.issue12397@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Yes, and ditto for 3.1.

----------
nosy: +terry.reedy
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12397>
_______________________________________

From report at bugs.python.org  Sat Jun 25 02:28:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 25 Jun 2011 00:28:37 +0000
Subject: [issue12374] Execution model should explain compile vs definition vs
	execution time
In-Reply-To: <1308582911.55.0.701954968644.issue12374@psf.upfronthosting.co.za>
Message-ID: <1308961717.22.0.539342039803.issue12374@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Most of my thoughts on this topic can be found at http://svn.python.org/view/sandbox/trunk/userref/ODF/ (that was written ~2.5, so some parts of it are a little dated, but the Essential Concepts section is still fairly accurate).

The most relevant part to the current discussion is 1.5:

1.5 Classes and Functions are Defined at Runtime
In static language such as Java or C++, function and class definitions are essentially directives to the language compiler regarding the nature of certain identifiers. While class and function definition statements still have implications for the compilation stage in Python, these definitions are also first class statements that are executed at runtime, just like any other statement. While the code within the function or class definition statement is compiled at compile time, the actual definition of the function or class does not occur until the statement is executed at runtime.
In top level code, this distinction usually doesn't matter, but it has some significant implications when class and function definitions are placed inside a function. Doing so means that a new class or a new function is defined every time the containing function is executed. This means that not only is it possible to have factory functions that create new class instances (as is common in all object-oriented languages), but it is also possible to have factory functions that create new classes or new functions. Another key feature of nested functions is that they employ lexical scoping, allowing nested functions to see identifiers defined in outer scopes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12374>
_______________________________________

From report at bugs.python.org  Sat Jun 25 02:32:09 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 25 Jun 2011 00:32:09 +0000
Subject: [issue12374] Execution model should explain compile vs definition vs
	execution time
In-Reply-To: <1308582911.55.0.701954968644.issue12374@psf.upfronthosting.co.za>
Message-ID: <1308961929.27.0.494373911788.issue12374@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The other directly relevant part is in section 5:

5.1.3 Evaluating Default Arguments
In static languages such as C, function definitions are instructions to the compiler rather than executable statements. This leads to such languages making distinctions between events that occur at run-time and at compile time. In Python, function definitions are statements in their own right, so run-time events related to functions are further divided into events that occur at definition time and at execution time. Definition time refers to the point where the function is defined by the def statement. Execution time refers to the point where the function is called and the body of the function is executed.
Where these distinctions matter the most is in the evaluation of default arguments, as this occurs only once at the time the function is defined. For immutable default values like numbers or the constant value None, this doesn't have any perceptible effect. For mutable defaults like lists and dictionaries, however, it makes a significant difference, as it means a single instance of the object is created at definition time, and is then shared across all invocations of the function that use the default argument value. This can result in unintended side effects. The typical approach to handling this situation is to use None as the default argument, and include code in the body of the function to create the appropriate default value when the parameter is set to None. The following listing shows the difference between the two mechanisms.
[Grab the ODF file if you want to see the code listing]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12374>
_______________________________________

From report at bugs.python.org  Sat Jun 25 02:34:34 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sat, 25 Jun 2011 00:34:34 +0000
Subject: [issue12403] Allow overriding of writing to stdout in
	code.InteractiveConsole
In-Reply-To: <1308959744.93.0.261089879651.issue12403@psf.upfronthosting.co.za>
Message-ID: <1308962074.62.0.515274338965.issue12403@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/issue12403>
_______________________________________

From report at bugs.python.org  Sat Jun 25 02:35:35 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jun 2011 00:35:35 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1308962135.96.0.28178483423.issue12291@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sat Jun 25 02:38:28 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sat, 25 Jun 2011 00:38:28 +0000
Subject: [issue6068] ctypes is not correctly handling bitfields backed by 64
	bit integers on Windows
In-Reply-To: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>
Message-ID: <1308962308.46.0.169395693312.issue6068@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/issue6068>
_______________________________________

From report at bugs.python.org  Sat Jun 25 02:47:57 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sat, 25 Jun 2011 00:47:57 +0000
Subject: [issue6068] ctypes is not correctly handling bitfields backed by 64
	bit integers on Windows
In-Reply-To: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>
Message-ID: <1308962877.47.0.871133366093.issue6068@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

FWIW, I tested the patch on a 64-bit Python build and test_ctypes passes with the new unittest added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6068>
_______________________________________

From report at bugs.python.org  Sat Jun 25 02:48:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Jun 2011 00:48:43 +0000
Subject: [issue12141] sysconfig.get_config_vars('srcdir') fails in specific
	cases
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1308962923.04.0.132435151042.issue12141@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think they are ready, I gave a +1 (with a typo: path instead of patch :) two messages ago.

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Sat Jun 25 02:52:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Jun 2011 00:52:55 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1308963175.72.0.0569624948673.issue11104@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your work, the code can now be fixed; I?ll have time to commit in a few days.

Can you check if the documentation still accurately describes the behavior?  (search for MANIFEST in Doc/distutils/*)

----------
stage:  -> commit review
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11104>
_______________________________________

From report at bugs.python.org  Sat Jun 25 03:00:59 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Jun 2011 01:00:59 +0000
Subject: [issue12399] simplify cell var initialization by storing constant
	data on the code object
In-Reply-To: <1308931560.13.0.00225198817974.issue12399@psf.upfronthosting.co.za>
Message-ID: <1308963659.06.0.62081613087.issue12399@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the review.

----------
Added file: http://bugs.python.org/file22450/bettercells2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12399>
_______________________________________

From report at bugs.python.org  Sat Jun 25 06:49:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Jun 2011 04:49:07 +0000
Subject: [issue12402] Overriding code.InteractiveConsole.write does not work
In-Reply-To: <1308955507.7.0.876307843842.issue12402@psf.upfronthosting.co.za>
Message-ID: <1308977347.53.0.101165817633.issue12402@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12402>
_______________________________________

From report at bugs.python.org  Sat Jun 25 07:02:05 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sat, 25 Jun 2011 05:02:05 +0000
Subject: [issue6069] casting error from ctypes array to structure
In-Reply-To: <1242815548.73.0.540935568828.issue6069@psf.upfronthosting.co.za>
Message-ID: <1308978125.42.0.864216889254.issue6069@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

I took a look at this and I believe behavior is correct on Windows, the issue is with the test. For example this test is failing:

class closest_fit(ctypes.BigEndianStructure):
    _pack_      = 1    # aligned to 8 bits, not ctypes default of 32
    _fields_    = [
                   ("Data0",   ctypes.c_uint32, 32),
                   ("Data1",   ctypes.c_uint8, 3),
                   ("Data2",   ctypes.c_uint16, 12),
                  ]

But you also have this assumption when generating the test data:

size_of_structures_in_bytes = 6

I verified and this does not hold with MSVC compiler. Using VC++ 2005, this code

typedef struct Test {
	unsigned int x: 32; // uint_32 : 32
	unsigned char y: 3; // uint_8 : 3
	unsigned short int z: 12; // uint_16 : 12
} Test;

gives sizeof(Test) == 7. In Python, if you look at sizeof(closest_fit), it will also be 7.

Looking at cfield.c, seems this was taken into account when creating bit fields:

    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
    } else if (bitsize) {
        /* start new bitfield */
        fieldtype = NEW_BITFIELD;
        *pbitofs = 0;
        *pfield_size = dict->size * 8;
 
Though I don't know this first-hand, above code plus sizeof experiment leads me to believe that gcc packs bitfields differently than MSVC. Seems that gcc will expand existing bitfield trying to pack structure more tightly so indeed on Linux (or I assume Windows gcc build), size of this structure is 6 as gcc will combine these seeing that an unsigned short can hold all 15 bits required but with MSVC this won't work. MSVC will allocate both the c_uint8 and the c_uint16 once is sees that last 12 bits don't fit in remaining c_uint8.

As far as I can tell this is by design and Python matches expected MSVC structure packing for this test case.

----------
nosy: +vladris

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6069>
_______________________________________

From report at bugs.python.org  Sat Jun 25 07:11:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Jun 2011 05:11:47 +0000
Subject: [issue12374] Execution model should explain compile vs definition vs
	execution time
In-Reply-To: <1308582911.55.0.701954968644.issue12374@psf.upfronthosting.co.za>
Message-ID: <1308978707.12.0.0404889796885.issue12374@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My understanding is that the language reference is a purposefully minimalist document that specifies the language (insofar as anything other than the CPython implementation does so).  So while better explanations of the implications of the language design are a good thing, they don't necessarily belong in the language reference.  (I'm not saying they don't, I'm just repeating what the intro says: "this is not a tutorial".)  In particular I am suspicious that statements that begin "in languages such as ..." don't belong in the language reference as it is currently written.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12374>
_______________________________________

From report at bugs.python.org  Sat Jun 25 07:32:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Jun 2011 05:32:17 +0000
Subject: [issue6068] ctypes is not correctly handling bitfields backed by 64
	bit integers on Windows
In-Reply-To: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>
Message-ID: <1308979937.42.0.403861846824.issue6068@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Adding our windows committers to nosy to see if this can be committed.

----------
nosy: +brian.curtin, r.david.murray, tim.golden
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6068>
_______________________________________

From report at bugs.python.org  Sat Jun 25 07:54:29 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sat, 25 Jun 2011 05:54:29 +0000
Subject: [issue6068] ctypes is not correctly handling bitfields backed by 64
	bit integers on Windows
In-Reply-To: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>
Message-ID: <1308981269.51.0.925414771735.issue6068@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Attaching patch as previous attachment is only unittest. I included change to SWAP_8 macro also as it looks like same issue and it will probably popup later.

----------
Added file: http://bugs.python.org/file22451/issue6068_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6068>
_______________________________________

From report at bugs.python.org  Sat Jun 25 08:37:05 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 25 Jun 2011 06:37:05 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>
Message-ID: <1308983825.3.0.453522807613.issue12303@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> What do you mean? signal.SIGPOLL exists in Python 3.3.

Right, si_band added.

> - test_sigwaitinfo(), test_sigtimedwait_poll(), test_sigwaitinfo_interrupted() are called from a child process. In test_wait(), I chose to write manually to stdout and call os._exit(1) (oh, I forgot an explicit sys.stdout.flush()). I don't know if you can use TestCase methods in a child process (I don't know what is written to stdout, _wait_helper() calls os._exit).

I assume you mean stderr? Well anyway if the assert* fails, an exception is raised and then caught by this code in wait_helper():
"""
except BaseException as err:
                print("error: {}".format(err), file=sys.stderr)
                sys.stderr.flush()
                os._exit(1)
"""
which prints it to stderr.
If this is OK, I'll commit the patch.

----------
Added file: http://bugs.python.org/file22452/issue12303_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Sat Jun 25 09:02:57 2011
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 25 Jun 2011 07:02:57 +0000
Subject: [issue12404] c99 code in mmapmodule
In-Reply-To: <1308985377.16.0.872851940652.issue12404@psf.upfronthosting.co.za>
Message-ID: <1308985377.16.0.872851940652.issue12404@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

Modules/mmapmodule.c contains code that makes it incompatible with C89 compiler.

People using recent gcc can check this by running following commands.
 
    $ ./configure CFLAGS='-Wdeclaration-after-statement' && make

Attached patch fixes the issue.
(verified on Linux 2.6.39-2-amd64 with gcc 4.6.1)

----------
components: Build
files: c89compat_mmap.patch
keywords: patch
messages: 139020
nosy: akitada
priority: normal
severity: normal
status: open
title: c99 code in mmapmodule
type: compile error
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22453/c89compat_mmap.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12404>
_______________________________________

From report at bugs.python.org  Sat Jun 25 09:33:11 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 25 Jun 2011 07:33:11 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308987191.56.0.420652551266.issue12394@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> In the setup.cfg files, scripts will now be a mapping of names to
> callables, like the setuptools scripts and gui_scripts entry points:
>
> scripts =
>     sphinx-build = sphinx.build.run

> On UNIX, a Python script named sphinx-build will be created, on
> Windows, a binary sphinx-build.exe will be created.

Perhaps some mechanism needs to be provided to indicate additional processing options per script line:

scripts =
    script-name = path.to.callable opt1 opt2 opt3

One specific practical use of this is to determine whether the Windows version will launch using the text mode launcher or the GUI mode launcher. For example:

scripts =
    sphinx-build = sphinx.build.run # No options => text-mode
    sphinx-gui = sphinx.gui.run win # Option "win" => gui-mode

This seems more future proof than an approach like providing for a separate gui-scripts entry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Sat Jun 25 09:36:36 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 25 Jun 2011 07:36:36 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1308987396.45.0.278874081237.issue12394@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Version independence always means version independence in the same
> major line of development (i.e. X number in X.Y.Z), or to put it
> another way, version independence among the versions listed as
> supported in the Trove classifiers.

That can still be a problem with e.g. byte literals: 2.5 will raise SyntaxError where 2.6, 2.7 will not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Sat Jun 25 10:02:51 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 25 Jun 2011 08:02:51 +0000
Subject: [issue12399] simplify cell var initialization by storing constant
	data on the code object
In-Reply-To: <1308931560.13.0.00225198817974.issue12399@psf.upfronthosting.co.za>
Message-ID: <1308988971.33.0.488159210788.issue12399@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Feel free to create a new issue about the incorrect size calculation on code objects, since it is apparently already broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12399>
_______________________________________

From report at bugs.python.org  Sat Jun 25 10:10:01 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Sat, 25 Jun 2011 08:10:01 +0000
Subject: [issue12382] [msilib] Obscure exception message when trying to open a
	non-existent MSI database
In-Reply-To: <1308658337.05.0.630810191443.issue12382@psf.upfronthosting.co.za>
Message-ID: <1308989401.91.0.0653120602535.issue12382@psf.upfronthosting.co.za>


Mark Mc Mahon <mtnbikingmark at gmail.com> added the comment:

The following two error conditions that can be returned by MsiOpenDatabase do not have specific handling:

ERROR_CREATE_FAILED (1631)
    The database could not be created.

ERROR_OPEN_FAILED (110)
    The database could not be opened as requested.

(the messages are those copied from MSDN).

Should extra cases for these go into the case statement in msierror? or should they be handled directly in OpenDatabase.

Does the error text above sound OK - should we add ": '%s'" % msi_file ?

----------
nosy: +markm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12382>
_______________________________________

From report at bugs.python.org  Sat Jun 25 10:11:53 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 25 Jun 2011 08:11:53 +0000
Subject: [issue12374] Execution model should explain compile vs definition vs
	execution time
In-Reply-To: <1308582911.55.0.701954968644.issue12374@psf.upfronthosting.co.za>
Message-ID: <1308989513.39.0.485061098401.issue12374@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Oh, agreed - the quotes above are from the "Python's User Reference" I wrote several years back, but never got around to converting from ODF and subsequently updating and publishing in a more accessible way.

It was designed to fill the gap that exists in the documentation between the tutorial (which gives usage information, but doesn't really explain how things work) and the language reference (which is a fairly minimalist spec that doesn't explain design intent or rationale very much). The associated publishing deal fell through so I got the copyrights back and donated the whole thing to the PSF.

However, the first step in making it more useful is extracting the text from the ODF files into reStructuredText and that's never made it to the top of my to-do list.

The ideal situation from my point of view would be for someone on doc-sig to help with the conversion process, but I've never had any takers (although I'll grant that the last time I asked was a number of years ago).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12374>
_______________________________________

From report at bugs.python.org  Sat Jun 25 10:14:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 08:14:19 +0000
Subject: [issue12404] c99 code in mmapmodule
In-Reply-To: <1308985377.16.0.872851940652.issue12404@psf.upfronthosting.co.za>
Message-ID: <E1QaO0P-0003mP-OD@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c72dafb14c49 by Ross Lagerwall in branch '2.7':
Issue 12404: Remove C89 incompatible code from mmap module.
http://hg.python.org/cpython/rev/c72dafb14c49

New changeset 567236a7122c by Ross Lagerwall in branch '3.2':
Issue 12404: Remove C89 incompatible code from mmap module.
http://hg.python.org/cpython/rev/567236a7122c

New changeset 04182fa5255b by Ross Lagerwall in branch 'default':
Merge with 3.2 (Issue #12404).
http://hg.python.org/cpython/rev/04182fa5255b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12404>
_______________________________________

From report at bugs.python.org  Sat Jun 25 10:17:03 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 25 Jun 2011 08:17:03 +0000
Subject: [issue12404] c99 code in mmapmodule
In-Reply-To: <1308985377.16.0.872851940652.issue12404@psf.upfronthosting.co.za>
Message-ID: <1308989823.94.0.611590672142.issue12404@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Thanks!

----------
assignee:  -> rosslagerwall
nosy: +rosslagerwall
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12404>
_______________________________________

From report at bugs.python.org  Sat Jun 25 11:00:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 09:00:20 +0000
Subject: [issue12164] str.translate docstring doesn't mention that 'table' can
	be None
In-Reply-To: <1306214084.99.0.386690557918.issue12164@psf.upfronthosting.co.za>
Message-ID: <E1QaOiw-0006ML-Sc@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 60b3a5615c4e by Mark Dickinson in branch '2.7':
Issue #12164: Document (in docstring) that str.translate accepts None for the first argument.
http://hg.python.org/cpython/rev/60b3a5615c4e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12164>
_______________________________________

From report at bugs.python.org  Sat Jun 25 11:01:08 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 25 Jun 2011 09:01:08 +0000
Subject: [issue12164] str.translate docstring doesn't mention that 'table' can
	be None
In-Reply-To: <1306214084.99.0.386690557918.issue12164@psf.upfronthosting.co.za>
Message-ID: <1308992468.97.0.974974520992.issue12164@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12164>
_______________________________________

From report at bugs.python.org  Sat Jun 25 11:05:56 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 25 Jun 2011 09:05:56 +0000
Subject: [issue12381] refactor slice checks made by methods that take "slice
	like" arguments
In-Reply-To: <1308628637.29.0.156287318778.issue12381@psf.upfronthosting.co.za>
Message-ID: <1308992756.66.0.201145911169.issue12381@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/issue12381>
_______________________________________

From report at bugs.python.org  Sat Jun 25 11:17:47 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Sat, 25 Jun 2011 09:17:47 +0000
Subject: [issue6474] Inconsistent TypeError message on function calls with
	wrong number of arguments
In-Reply-To: <1247495805.32.0.528519491274.issue6474@psf.upfronthosting.co.za>
Message-ID: <1308993467.98.0.106549962952.issue6474@psf.upfronthosting.co.za>


Oleg Oshmyan <chortos at inbox.lv> added the comment:

Yes, thank you. I am (yet) unable to create a misleading error message now. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6474>
_______________________________________

From report at bugs.python.org  Sat Jun 25 11:22:21 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Sat, 25 Jun 2011 09:22:21 +0000
Subject: [issue8623] Aliasing warnings in socketmodule.c
In-Reply-To: <1273067856.13.0.617035378143.issue8623@psf.upfronthosting.co.za>
Message-ID: <1308993741.58.0.888998483123.issue8623@psf.upfronthosting.co.za>


Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com> added the comment:

I can't reproduce both these cases with gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2 on i386 using the current default branch (70943:024827a9db64).

----------
nosy: +Kristian.Vlaardingerbroek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8623>
_______________________________________

From report at bugs.python.org  Sat Jun 25 11:25:52 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 25 Jun 2011 09:25:52 +0000
Subject: [issue12245] Document the meaning of FLT_ROUNDS constants for
	sys.float_info
In-Reply-To: <1307044030.93.0.176037757521.issue12245@psf.upfronthosting.co.za>
Message-ID: <1308993952.55.0.306232862125.issue12245@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> all it does is give information about the FPU settings at the time that
> Python was compiled

Hmm.  It's actually a bit better than that:  as far as I can tell, it reflects the value of FLT_ROUNDS at the time that Python is started (when the sys module is initialized).  OTOH, FLT_ROUNDS on my machine is #define'd to be 1, in violation of the C standards.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12245>
_______________________________________

From report at bugs.python.org  Sat Jun 25 11:34:26 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 25 Jun 2011 09:34:26 +0000
Subject: [issue12245] Document the meaning of FLT_ROUNDS constants for
	sys.float_info
In-Reply-To: <1307044030.93.0.176037757521.issue12245@psf.upfronthosting.co.za>
Message-ID: <1308994466.29.0.519603232986.issue12245@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Patch that elaborates a bit on the meaning of sys.float_info.rounds.

----------
keywords: +patch
Added file: http://bugs.python.org/file22454/issue12245.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12245>
_______________________________________

From report at bugs.python.org  Sat Jun 25 11:38:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Jun 2011 09:38:16 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>
Message-ID: <1308994696.21.0.653374631636.issue12303@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> If this is OK, I'll commit the patch.

Yep, this version is the good one. Please keep the issue open until the test pass on all buildbots. Each newly added signal functions took me some days to fix the test for Mac OS X and/or FreeBSD 6. But you are maybe more lucky than me ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Sat Jun 25 11:38:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 09:38:32 +0000
Subject: [issue12341] Some additions to .hgignore
In-Reply-To: <1308156137.45.0.893152397766.issue12341@psf.upfronthosting.co.za>
Message-ID: <E1QaPJu-0008WQ-AN@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset eaaa073a9a42 by Ezio Melotti in branch '3.2':
#12341: add coverage files/dirs to .hgignore. Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/eaaa073a9a42

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12341>
_______________________________________

From report at bugs.python.org  Sat Jun 25 11:46:07 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 25 Jun 2011 09:46:07 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>
Message-ID: <1308995167.23.0.196187467696.issue9990@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee: mark.dickinson -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9990>
_______________________________________

From report at bugs.python.org  Sat Jun 25 11:47:11 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 25 Jun 2011 09:47:11 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1308995231.23.0.934867453491.issue10227@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee: mark.dickinson -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Sat Jun 25 11:48:25 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 25 Jun 2011 09:48:25 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1308995305.23.0.132392157923.issue12405@psf.upfronthosting.co.za>
Message-ID: <1308995305.23.0.132392157923.issue12405@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

pysetup3 install should not only record files that it installs, but also any directories it creates. pysetup3 remove should then delete those directories (if empty after removing their installed contents).

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 139035
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: normal
severity: normal
status: open
title: packaging does not record/remove directories it creates
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Sat Jun 25 11:59:10 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 25 Jun 2011 09:59:10 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1308995950.75.0.288905614048.issue12406@psf.upfronthosting.co.za>
Message-ID: <1308995950.75.0.288905614048.issue12406@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

I know it's early days yet, but I've tried to create an MSI for Python 3.3. I was able to do so, but I had to make some changes to msi.py (patch attached).

----------
components: Build, Demos and Tools, Windows
files: msi.py.diff
keywords: patch
messages: 139036
nosy: loewis, vinay.sajip
priority: normal
severity: normal
status: open
title: msi.py needs updating for Python 3.3
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file22455/msi.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12406>
_______________________________________

From report at bugs.python.org  Sat Jun 25 12:03:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 10:03:00 +0000
Subject: [issue12228] Stat doc - fix swap of UF_OPAQUE and UF_NOUNLINK
	description
In-Reply-To: <1306864902.26.0.858229152162.issue12228@psf.upfronthosting.co.za>
Message-ID: <E1QaPha-0001OU-Rl@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d912dfb7ab7a by Mark Dickinson in branch '2.7':
Issue #12228: Fix exchanged flag descriptions in stat.rst.  Thanks Sandro Tosi.
http://hg.python.org/cpython/rev/d912dfb7ab7a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12228>
_______________________________________

From report at bugs.python.org  Sat Jun 25 12:05:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 10:05:35 +0000
Subject: [issue12228] Stat doc - fix swap of UF_OPAQUE and UF_NOUNLINK
	description
In-Reply-To: <1306864902.26.0.858229152162.issue12228@psf.upfronthosting.co.za>
Message-ID: <E1QaPk6-0001cx-96@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 03c8de42c206 by Mark Dickinson in branch '3.1':
Issue #12228: Fix exchanged flag descriptions in stat.rst.  Thanks Sandro Tosi.
http://hg.python.org/cpython/rev/03c8de42c206

New changeset 4a3e528b6b11 by Mark Dickinson in branch '3.2':
Merge #12228
http://hg.python.org/cpython/rev/4a3e528b6b11

New changeset 6c6ee4eb27f8 by Mark Dickinson in branch 'default':
Merge #12228
http://hg.python.org/cpython/rev/6c6ee4eb27f8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12228>
_______________________________________

From report at bugs.python.org  Sat Jun 25 12:07:02 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 25 Jun 2011 10:07:02 +0000
Subject: [issue12228] Stat doc - fix swap of UF_OPAQUE and UF_NOUNLINK
	description
In-Reply-To: <1306864902.26.0.858229152162.issue12228@psf.upfronthosting.co.za>
Message-ID: <1308996422.18.0.645848402573.issue12228@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the patch!

----------
nosy: +mark.dickinson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12228>
_______________________________________

From report at bugs.python.org  Sat Jun 25 12:15:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 10:15:09 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>
Message-ID: <E1QaPtM-00027N-GW@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1137f7021b95 by Ross Lagerwall in branch 'default':
Issue #12303: Add sigwaitinfo() and sigtimedwait() to the signal module.
http://hg.python.org/cpython/rev/1137f7021b95

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Sat Jun 25 12:16:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 10:16:35 +0000
Subject: [issue10326] Can't pickle unittest.TestCase instances
In-Reply-To: <1288966649.03.0.6620170389.issue10326@psf.upfronthosting.co.za>
Message-ID: <E1QaPuk-0002An-L4@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9c337a4c650d by Raymond Hettinger in branch '2.7':
Issue 10326: Fix regression to get test cases to pickle again.
http://hg.python.org/cpython/rev/9c337a4c650d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10326>
_______________________________________

From report at bugs.python.org  Sat Jun 25 12:18:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Jun 2011 10:18:10 +0000
Subject: [issue10326] Can't pickle unittest.TestCase instances
In-Reply-To: <1288966649.03.0.6620170389.issue10326@psf.upfronthosting.co.za>
Message-ID: <1308997090.26.0.0361236112202.issue10326@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/issue10326>
_______________________________________

From report at bugs.python.org  Sat Jun 25 12:43:11 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 25 Jun 2011 10:43:11 +0000
Subject: [issue5114] 2.7:  test_threading hangs on Solaris
In-Reply-To: <1233347094.1.0.608806299681.issue5114@psf.upfronthosting.co.za>
Message-ID: <1308998591.22.0.775201338213.issue5114@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I'm closing.
Feel free to re-open if this fails with 2.7 or 3.2.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Throw away more radioactive locks that could be held across a fork in threading.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5114>
_______________________________________

From report at bugs.python.org  Sat Jun 25 12:44:46 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Sat, 25 Jun 2011 10:44:46 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1308998686.21.0.00891752539292.issue10845@psf.upfronthosting.co.za>


Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com> added the comment:

This has been committed a while ago, can this issue be closed?

----------
nosy: +Kristian.Vlaardingerbroek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Sat Jun 25 13:02:08 2011
From: report at bugs.python.org (Cesare Di Mauro)
Date: Sat, 25 Jun 2011 11:02:08 +0000
Subject: [issue12407] test_subinterps fails on Windows
In-Reply-To: <1308999728.78.0.684048233766.issue12407@psf.upfronthosting.co.za>
Message-ID: <1308999728.78.0.684048233766.issue12407@psf.upfronthosting.co.za>


New submission from Cesare Di Mauro <cesare.di.mauro at gmail.com>:

This test fails on Windows because it tries to change the working folder to an empty string.
Anyway, even changing:
    os.chdir(basepath)
with:
    os.chdir(basepath or '.')
it fails because the subprocess tries to execute an ELF file ('Modules/_testembed') which Windows isn't able to handle.

----------
components: Tests, Windows
files: test_capi.py.patch
keywords: patch
messages: 139044
nosy: brian.curtin, cdimauro, pitrou
priority: normal
severity: normal
status: open
title: test_subinterps fails on Windows
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file22456/test_capi.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12407>
_______________________________________

From report at bugs.python.org  Sat Jun 25 13:22:01 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Jun 2011 11:22:01 +0000
Subject: [issue10583] Encoding issue with chm help in 2.7.1
In-Reply-To: <1291060108.22.0.631034667944.issue10583@psf.upfronthosting.co.za>
Message-ID: <1309000921.43.0.352183232687.issue10583@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello, can you still replicate it with 2.7.2 ?

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10583>
_______________________________________

From report at bugs.python.org  Sat Jun 25 13:23:47 2011
From: report at bugs.python.org (Cesare Di Mauro)
Date: Sat, 25 Jun 2011 11:23:47 +0000
Subject: [issue12408] Relative import used on test_future5
In-Reply-To: <1309001027.05.0.416660264126.issue12408@psf.upfronthosting.co.za>
Message-ID: <1309001027.05.0.416660264126.issue12408@psf.upfronthosting.co.za>


New submission from Cesare Di Mauro <cesare.di.mauro at gmail.com>:

Executing test_future5 fails:

D:\CPython>PCbuild\python_d.exe Lib\test\test_future5.py
Traceback (most recent call last):
  File "Lib\test\test_future5.py", line 6, in <module>
    from . import support
ValueError: Attempted relative import in non-package
[51279 refs]

Tested on Windows 7.

----------
components: Tests
files: test_future5.py.patch
keywords: patch
messages: 139046
nosy: cdimauro
priority: normal
severity: normal
status: open
title: Relative import used on test_future5
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22457/test_future5.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12408>
_______________________________________

From report at bugs.python.org  Sat Jun 25 13:30:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 11:30:13 +0000
Subject: [issue12408] Relative import used on test_future5
In-Reply-To: <1309001027.05.0.416660264126.issue12408@psf.upfronthosting.co.za>
Message-ID: <E1QaR3z-00060n-OG@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c5fca67a7e8c by Mark Dickinson in branch '3.2':
Issue #12408: Fix relative import in test_future5.py.  Thanks Cesare Di Mauro.
http://hg.python.org/cpython/rev/c5fca67a7e8c

New changeset 898c0c8ba8ca by Mark Dickinson in branch 'default':
Issue #12408: Merge.
http://hg.python.org/cpython/rev/898c0c8ba8ca

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12408>
_______________________________________

From report at bugs.python.org  Sat Jun 25 13:31:14 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 25 Jun 2011 11:31:14 +0000
Subject: [issue12408] Relative import used on test_future5
In-Reply-To: <1309001027.05.0.416660264126.issue12408@psf.upfronthosting.co.za>
Message-ID: <1309001474.65.0.426275359681.issue12408@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report.

----------
nosy: +mark.dickinson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12408>
_______________________________________

From report at bugs.python.org  Sat Jun 25 14:14:21 2011
From: report at bugs.python.org (Robin Jarry)
Date: Sat, 25 Jun 2011 12:14:21 +0000
Subject: [issue12382] [msilib] Obscure exception message when trying to open a
	non-existent MSI database
In-Reply-To: <1308658337.05.0.630810191443.issue12382@psf.upfronthosting.co.za>
Message-ID: <1309004061.43.0.164585029255.issue12382@psf.upfronthosting.co.za>


Robin Jarry <diabeteman at gmail.com> added the comment:

This sounds OK as long as the error message is explicit :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12382>
_______________________________________

From report at bugs.python.org  Sat Jun 25 14:38:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Jun 2011 12:38:57 +0000
Subject: [issue11163] iter() documentation code doesn't work
In-Reply-To: <1297284045.4.0.795458647498.issue11163@psf.upfronthosting.co.za>
Message-ID: <1309005537.96.0.412373573175.issue11163@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/issue11163>
_______________________________________

From report at bugs.python.org  Sat Jun 25 14:48:59 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Sat, 25 Jun 2011 12:48:59 +0000
Subject: [issue10020] docs for sqlite3 describe functions not available
	without recompiling
In-Reply-To: <1286124753.24.0.309036392806.issue10020@psf.upfronthosting.co.za>
Message-ID: <1309006139.5.0.464635371552.issue10020@psf.upfronthosting.co.za>


Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com> added the comment:

Attached patch for Python 2.7. 

Since Issue10268 has not been applied to Python 2.7 the sentence "you must modify setup.py and and remove the line that sets SQLITE_OMIT_LOAD_EXTENSION" still applies.

----------
keywords: +patch
nosy: +Kristian.Vlaardingerbroek
Added file: http://bugs.python.org/file22458/issue10020-python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10020>
_______________________________________

From report at bugs.python.org  Sat Jun 25 14:57:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 12:57:13 +0000
Subject: [issue11889] 'enumerate' 'start' parameter documentation is confusing
In-Reply-To: <1303315736.72.0.416681647484.issue11889@psf.upfronthosting.co.za>
Message-ID: <E1QaSQC-0003Fk-Hi@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0ca8ffffd90b by Raymond Hettinger in branch '2.7':
Issue 11889: Clarify docs for enumerate.
http://hg.python.org/cpython/rev/0ca8ffffd90b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11889>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:00:52 2011
From: report at bugs.python.org (engelbert gruber)
Date: Sat, 25 Jun 2011 13:00:52 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1309006852.91.0.853919475979.issue11197@psf.upfronthosting.co.za>


engelbert gruber <grubert at users.sourceforge.net> added the comment:

SimpleHTTPServer does not exist in Python3.1 up instead http.server.

All versions (3.x 2011-06-25) reply the contents from the served directory on a request of the upper directory and act similar with files.

Maybe documentation needs an update documentation.

----------
nosy: +grubert
versions:  -Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11197>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:01:08 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Sat, 25 Jun 2011 13:01:08 +0000
Subject: [issue10583] Encoding issue with chm help in 2.7.1
In-Reply-To: <1291060108.22.0.631034667944.issue10583@psf.upfronthosting.co.za>
Message-ID: <1309006868.15.0.0452553603566.issue10583@psf.upfronthosting.co.za>


Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com> added the comment:

I can reproduce the issue with Python 2.7.2 and Python 3.2 on Windows 7 Enterprise SP 1 64-bit.

----------
nosy: +Kristian.Vlaardingerbroek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10583>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:01:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 13:01:22 +0000
Subject: [issue11889] 'enumerate' 'start' parameter documentation is confusing
In-Reply-To: <1303315736.72.0.416681647484.issue11889@psf.upfronthosting.co.za>
Message-ID: <E1QaSUD-0003TV-KZ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d0df12b32522 by Raymond Hettinger in branch '3.2':
Issue 11889: Clarify docs for enumerate.
http://hg.python.org/cpython/rev/d0df12b32522

New changeset 9b827e3998f6 by Raymond Hettinger in branch 'default':
Issue 11889: Clarify docs for enumerate.
http://hg.python.org/cpython/rev/9b827e3998f6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11889>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:02:18 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Jun 2011 13:02:18 +0000
Subject: [issue11889] 'enumerate' 'start' parameter documentation is confusing
In-Reply-To: <1303315736.72.0.416681647484.issue11889@psf.upfronthosting.co.za>
Message-ID: <1309006938.28.0.00205964610947.issue11889@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/issue11889>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:04:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 13:04:40 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>
Message-ID: <E1QaSXP-0003XL-6Y@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 768234f5c246 by Ross Lagerwall in branch 'default':
Fix test_signal on Windows after #12303.
http://hg.python.org/cpython/rev/768234f5c246

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:06:54 2011
From: report at bugs.python.org (engelbert gruber)
Date: Sat, 25 Jun 2011 13:06:54 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1309007214.34.0.886964815084.issue11197@psf.upfronthosting.co.za>


engelbert gruber <grubert at users.sourceforge.net> added the comment:

My test setup:

  test.html
  2.5/test.html
  2.7/test.html

in 2.5 and 2.7 execute ::

  python.exe -m SimpleHTTPServer 8000

``http://localhost:8000/../`` shows the contents of the ``2.x`` directory.

``http://localhost:8000/../test.html`` shows the contents of the file in the ``2.x`` directory not the one in the upper.

Should be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11197>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:07:15 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 25 Jun 2011 13:07:15 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1309007235.53.0.348351059768.issue10845@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, the broader issue with multiprocessing, Windows and state held in the main module is covered by PEP 395, so there's no need to double up by keeping this open.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:08:12 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Jun 2011 13:08:12 +0000
Subject: [issue10583] Encoding issue with chm help in 2.7.1
In-Reply-To: <1291060108.22.0.631034667944.issue10583@psf.upfronthosting.co.za>
Message-ID: <1309007292.87.0.107864677184.issue10583@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Adding Georg to nosy, he might now how CHM is generated on Windows and shine some light here

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10583>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:18:44 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Jun 2011 13:18:44 +0000
Subject: [issue11758] increase xml.dom.minidom test coverage
In-Reply-To: <1301892434.54.0.122832391998.issue11758@psf.upfronthosting.co.za>
Message-ID: <1309007924.41.0.0700069775086.issue11758@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I checked the patch, and it works (in 2.7, 3.2 and default) and it would be nice if it can be committed.

----------
nosy: +sandro.tosi
stage:  -> commit review
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11758>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:19:13 2011
From: report at bugs.python.org (mouad)
Date: Sat, 25 Jun 2011 13:19:13 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1309007953.55.0.256591851637.issue12157@psf.upfronthosting.co.za>


Changes by mouad <mouadino at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22459/pool.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12157>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:20:58 2011
From: report at bugs.python.org (mouad)
Date: Sat, 25 Jun 2011 13:20:58 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1309008058.25.0.331949246739.issue12157@psf.upfronthosting.co.za>


Changes by mouad <mouadino at gmail.com>:


Added file: http://bugs.python.org/file22460/test_multiprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12157>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:23:31 2011
From: report at bugs.python.org (mouad)
Date: Sat, 25 Jun 2011 13:23:31 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1309008211.95.0.881060365634.issue12157@psf.upfronthosting.co.za>


Changes by mouad <mouadino at gmail.com>:


Added file: http://bugs.python.org/file22461/support.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12157>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:24:40 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Sat, 25 Jun 2011 13:24:40 +0000
Subject: [issue10583] Encoding issue with chm help in 2.7.1
In-Reply-To: <1291060108.22.0.631034667944.issue10583@psf.upfronthosting.co.za>
Message-ID: <1309008280.42.0.418407002727.issue10583@psf.upfronthosting.co.za>


Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com> added the comment:

I've looked at the output from make html and make htmlhelp and taking the library/json.html as example the text between <title> </title> is exactly the same.

Chrome renders both fine:

<title>18.2. json ? JSON encoder and decoder &mdash; Python v2.7.2 documentation</title>

But when looking at the file in the HTML Help Workshop it looks like this:

 <title>18.2. json ??? JSON encoder and decoder</title>

Which is what you see when doing the search.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10583>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:26:13 2011
From: report at bugs.python.org (engelbert gruber)
Date: Sat, 25 Jun 2011 13:26:13 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1309008373.55.0.0808496751497.issue11197@psf.upfronthosting.co.za>


Changes by engelbert gruber <grubert at users.sourceforge.net>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11197>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:31:49 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Jun 2011 13:31:49 +0000
Subject: [issue11758] increase xml.dom.minidom test coverage
In-Reply-To: <1301892434.54.0.122832391998.issue11758@psf.upfronthosting.co.za>
Message-ID: <1309008709.64.0.257464478515.issue11758@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11758>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:33:56 2011
From: report at bugs.python.org (Sara Magliacane)
Date: Sat, 25 Jun 2011 13:33:56 +0000
Subject: [issue11763] assertEqual memory issues with large text inputs
In-Reply-To: <1301948164.44.0.0206798295308.issue11763@psf.upfronthosting.co.za>
Message-ID: <1309008836.84.0.502698485195.issue11763@psf.upfronthosting.co.za>


Sara Magliacane <sara.magliacane at gmail.com> added the comment:

Here is a small patch addressing the second point of the last message, but the tests are still missing.

----------
nosy: +sara.magliacane
Added file: http://bugs.python.org/file22462/issue11763_safe_repr.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11763>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:36:08 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Jun 2011 13:36:08 +0000
Subject: [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi! We have the devguide now, and it should be the place where to look for references and docs about contributing to Python, that means also for the documentation.

In the official Python doc we have a section "Documenting Python" (http://docs.python.org/py3k/documenting/index.html) and I think it should be merged into the devguide - what's your opinion on that?

----------
assignee: docs at python
components: Documentation
messages: 139062
nosy: brett.cannon, docs at python, ezio.melotti, georg.brandl, sandro.tosi
priority: normal
severity: normal
status: open
title: Moving "Documenting Python" to Devguide

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12409>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:38:14 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Sat, 25 Jun 2011 13:38:14 +0000
Subject: [issue10583] Encoding issue with chm help in 2.7.1
In-Reply-To: <1291060108.22.0.631034667944.issue10583@psf.upfronthosting.co.za>
Message-ID: <1309009094.76.0.558289084952.issue10583@psf.upfronthosting.co.za>


Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com> added the comment:

This might be non-fixable:

http://support.microsoft.com/kb/269766/

HTML Help 1.x does not compile the Unicode characters. Meaning that in the search and index views you'll get garbage. For the rest of the rendering IE is used which does render the correct characters.

There is support in HTML Help 2.x but as far as I can see that is only available as a component in Visual Studio and not included with a default Windows installation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10583>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:39:07 2011
From: report at bugs.python.org (mouad)
Date: Sat, 25 Jun 2011 13:39:07 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1309009147.76.0.823178137725.issue12157@psf.upfronthosting.co.za>


mouad <mouadino at gmail.com> added the comment:

Hello,

This is my first patch to cpython, hope it will be accepted :)

The fix that i did is to remove the ResultMap instance from the pool cache when the iterable is empty. 

In general here is what happen: The "map" method create a MapResult instance, which add it self automatically to the pool._cache and this ResultMap instance will be used by the task that will be created and added after in the "pool._taskqueue" to communicate the task result, but in case of an empty iterable the task will not be created and we will end up with a MapResult with no task and when we will try to join the pool, it will hang waiting for the task to set the result in the MapResult instance.

For the test i created a new helper `operation_timeout` that is used as a contextmanager to make sure that the test will not hang for ever, i don't know if it's useful maybe just running the test without checking for any timeout is more *realistic*.

----------
nosy: +mouad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12157>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:54:24 2011
From: report at bugs.python.org (Stephen Thorne)
Date: Sat, 25 Jun 2011 13:54:24 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1309010064.11.0.990949803812.issue11104@psf.upfronthosting.co.za>


Stephen Thorne <stephen at thorne.id.au> added the comment:

?ric mentioned that i should check that this behaviour matches the documentation. I have gone and looked for all instances of MANIFEST in the documentation and found one place which was inconsistent. I've added the doc patch to the patch. Please review this new version.

----------
Added file: http://bugs.python.org/file22463/manifest-respect-3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11104>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:55:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 13:55:00 +0000
Subject: [issue11758] increase xml.dom.minidom test coverage
In-Reply-To: <1301892434.54.0.122832391998.issue11758@psf.upfronthosting.co.za>
Message-ID: <E1QaTK6-0006SE-NU@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 79d61e2050cd by Raymond Hettinger in branch 'default':
Issue 11758: increase xml.dom.minidom test coverage (contributed by mdorn, reviewed by Sandro Tosi).
http://hg.python.org/cpython/rev/79d61e2050cd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11758>
_______________________________________

From report at bugs.python.org  Sat Jun 25 15:56:00 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Jun 2011 13:56:00 +0000
Subject: [issue11758] increase xml.dom.minidom test coverage
In-Reply-To: <1301892434.54.0.122832391998.issue11758@psf.upfronthosting.co.za>
Message-ID: <1309010160.13.0.269683642602.issue11758@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11758>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:08:41 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Sat, 25 Jun 2011 14:08:41 +0000
Subject: [issue10020] docs for sqlite3 describe functions not available
	without recompiling
In-Reply-To: <1286124753.24.0.309036392806.issue10020@psf.upfronthosting.co.za>
Message-ID: <1309010921.44.0.484962977867.issue10020@psf.upfronthosting.co.za>


Changes by Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com>:


Removed file: http://bugs.python.org/file22458/issue10020-python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10020>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:09:05 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Sat, 25 Jun 2011 14:09:05 +0000
Subject: [issue10020] docs for sqlite3 describe functions not available
	without recompiling
In-Reply-To: <1286124753.24.0.309036392806.issue10020@psf.upfronthosting.co.za>
Message-ID: <1309010945.83.0.670447322063.issue10020@psf.upfronthosting.co.za>


Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com> added the comment:

Fixed typo (double and).

----------
Added file: http://bugs.python.org/file22464/issue10020-python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10020>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:17:18 2011
From: report at bugs.python.org (=?utf-8?b?VG9tYcW+IMWgb2xj?=)
Date: Sat, 25 Jun 2011 14:17:18 +0000
Subject: [issue7123] Multiprocess Process does not always exit when run from a
	thread.
In-Reply-To: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
Message-ID: <1309011438.3.0.914077996362.issue7123@psf.upfronthosting.co.za>


Toma? ?olc <tomaz.solc at tablix.org> added the comment:

I am pretty sure this is another instance of issue 6721.

multiprocessing is forking a new process and if that happens while the other thread is holding the lock for stdout, the process will deadlock because the lock state is replicated in the subprocess while the thread that is supposed unlock it isn't (even if you remove all prints, the deadlock will happen on a stdout flush).

Attaching a gdb to a hung subprocess confirms that it is waiting for a lock in the bufferedio module.

I've reproduced this on Python trunk running on Linux (using pthreads) and can confirm that the patch attached to issue 6721 fixes it.

I'm also attaching a shorter test case that omits unused code from the original example.

----------
nosy: +avian
Added file: http://bugs.python.org/file22465/testing.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7123>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:18:30 2011
From: report at bugs.python.org (Stephen Thorne)
Date: Sat, 25 Jun 2011 14:18:30 +0000
Subject: [issue10510] distutils upload/register should use CRLF in HTTP
	requests
In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za>
Message-ID: <1309011510.3.0.344679994805.issue10510@psf.upfronthosting.co.za>


Stephen Thorne <stephen at thorne.id.au> added the comment:

I'm having a look at this ticket now. It looks like this can be rewritten to use common code, and it would probably be good to use the 'email' module for creating the MIME segements properly.

----------
nosy: +jerub

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:24:00 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Jun 2011 14:24:00 +0000
Subject: [issue11551] test_dummy_thread.py test coverage improvement
In-Reply-To: <1300167076.06.0.564640850905.issue11551@psf.upfronthosting.co.za>
Message-ID: <1309011840.65.0.146934829624.issue11551@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I run a review on rietveld, just minor stuff (even though I don't see the 100% coverage).

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11551>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:28:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 14:28:23 +0000
Subject: [issue12086] Tutorial doesn't discourage name mangling
In-Reply-To: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>
Message-ID: <E1QaTqP-0000AS-Sj@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 68bc3c5960a4 by Raymond Hettinger in branch '2.7':
Issue 12086: add example showing how to use name mangling.
http://hg.python.org/cpython/rev/68bc3c5960a4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12086>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:31:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 14:31:23 +0000
Subject: [issue12086] Tutorial doesn't discourage name mangling
In-Reply-To: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>
Message-ID: <E1QaTtJ-0000Pt-TG@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 79f9698777b7 by Raymond Hettinger in branch '3.2':
Issue 12086: add example showing how to use name mangling.
http://hg.python.org/cpython/rev/79f9698777b7

New changeset fca745bc70be by Raymond Hettinger in branch 'default':
Issue 12086: add example showing how to use name mangling.
http://hg.python.org/cpython/rev/fca745bc70be

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12086>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:32:23 2011
From: report at bugs.python.org (mouad)
Date: Sat, 25 Jun 2011 14:32:23 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1309012343.13.0.0577063471269.issue12157@psf.upfronthosting.co.za>


Changes by mouad <mouadino at gmail.com>:


Removed file: http://bugs.python.org/file22459/pool.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12157>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:32:28 2011
From: report at bugs.python.org (mouad)
Date: Sat, 25 Jun 2011 14:32:28 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1309012348.01.0.792450125031.issue12157@psf.upfronthosting.co.za>


Changes by mouad <mouadino at gmail.com>:


Removed file: http://bugs.python.org/file22460/test_multiprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12157>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:32:30 2011
From: report at bugs.python.org (mouad)
Date: Sat, 25 Jun 2011 14:32:30 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1309012350.93.0.260674473182.issue12157@psf.upfronthosting.co.za>


Changes by mouad <mouadino at gmail.com>:


Removed file: http://bugs.python.org/file22461/support.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12157>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:32:56 2011
From: report at bugs.python.org (mouad)
Date: Sat, 25 Jun 2011 14:32:56 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1309012376.99.0.294979607202.issue12157@psf.upfronthosting.co.za>


Changes by mouad <mouadino at gmail.com>:


Added file: http://bugs.python.org/file22466/issue-12157.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12157>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:35:48 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Jun 2011 14:35:48 +0000
Subject: [issue12086] Tutorial doesn't discourage name mangling
In-Reply-To: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>
Message-ID: <1309012548.94.0.100642481215.issue12086@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Added an example of how to use double underscores correctly.  

I agree with Ezio that the rest of the documentation is clear on the subject.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12086>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:43:29 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Jun 2011 14:43:29 +0000
Subject: [issue12403] Mention sys.displayhook in code module docs and the
	compile builtin docs
In-Reply-To: <1308959744.93.0.261089879651.issue12403@psf.upfronthosting.co.za>
Message-ID: <1309013009.33.0.57885083201.issue12403@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, the code is being executed by an exec call on a code object that was compiled with the 'single' flag, which is what causes non-None values to get "printed".  The compile docs aren't clear on how "printed" is implemented, but the answer is that it calls sys.displayhook.  So the way to control that part of the output is to assign your own function to sys.displayhook.  None of this is documented, and it should be (it took me a while to figure it out, and I had a suspicions about how it worked), so I'm changing this to a documentation bug.

However, you mention in the other ticket that are trying to do the interactive interpreter trick through a socket.  For that application I think you want to ignore both the write method and sys.displayhook, and instead directly patch sys.stdout and sys.stderr. Otherwise you'd also miss output sent to those destinations via print statements or writing directly to the sys objects, which would confuse the user of your interface since the in the normal interactive prompt those show up on the console.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray
stage:  -> needs patch
title: Allow overriding of writing to stdout in code.InteractiveConsole -> Mention sys.displayhook in code module docs and the compile builtin docs
type: feature request -> behavior
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12403>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:48:55 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Jun 2011 14:48:55 +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: <1309013335.79.0.324924667077.issue11869@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/issue11869>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:49:36 2011
From: report at bugs.python.org (mouad)
Date: Sat, 25 Jun 2011 14:49:36 +0000
Subject: [issue12410] Create a new helper function that enable to test that an
	operation don't hang more than a given timeout.
In-Reply-To: <1309013375.96.0.63412212065.issue12410@psf.upfronthosting.co.za>
Message-ID: <1309013375.96.0.63412212065.issue12410@psf.upfronthosting.co.za>


New submission from mouad <mouadino at gmail.com>:

While working on issue #12157 [http://bugs.python.org/issue12157], I needed a function that make sure that an operation will not hang forever, for this reason i have create this helper function that support the context manager protocol and accept a timeout as an argument and raise an IOError if the operation didn't terminate before that timeout.

----------
components: Tests
files: operation_timeout.patch
keywords: patch
messages: 139075
nosy: mouad
priority: normal
severity: normal
status: open
title: Create a new helper function that enable to test that an operation don't hang more than a given timeout.
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file22467/operation_timeout.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12410>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:51:10 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 25 Jun 2011 14:51:10 +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: <1309013470.09.0.843007318752.issue11870@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

test_2_join_in_forked_process fails on FreeBSD 6.4 buildbot.
http://www.python.org/dev/buildbot/all/builders/x86 FreeBSD 6.4 3.x/builds/1606/steps/test/logs/stdio

"""
======================================================================
FAIL: test_2_join_in_forked_process (test.test_threading.ThreadJoinOnShutdown)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_threading.py", line 464, in test_2_join_in_forked_process
    self._run_and_join(script)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_threading.py", line 436, in _run_and_join
    self.assertEqual(data, "end of main\nend of thread\n")
AssertionError: '' != 'end of main\nend of thread\n'
+ end of main
+ end of thread
"""

I think it's the same problem as issue #12316: in the child process, even calling pthread_create can segfault/abort on FreeBSD6 (async-safe blahblah...).
Tests creating a thread from a fork()ed process should be skipped on FreeBSD6.
Patch attached, along with some refactoring to use the skipIf idiom.

As for test_3_join_in_forked_from_thread, well, it could be more or less the same problem. We're really doing something prohibited by POSIX, so things might break in unexpected ways. For example, calling pthread_condition_destroy from the child process can deadlock (see http://bugs.python.org/issue6721#msg136047).

Victor: to debug this kind of problem, it would be great if faulthandler could also dump tracebacks of children processes. Do you mind if I create a new issue?

----------
keywords: +patch
nosy: +neologix
Added file: http://bugs.python.org/file22468/test_threading_fork.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11870>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:52:58 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Sat, 25 Jun 2011 14:52:58 +0000
Subject: [issue12403] Mention sys.displayhook in code module docs and the
	compile builtin docs
In-Reply-To: <1308959744.93.0.261089879651.issue12403@psf.upfronthosting.co.za>
Message-ID: <1309013578.32.0.380609652381.issue12403@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

Yeah, I though about using dup2 from stdout/stderr to the socket. However this means I can connect only one client at a time. Which was an issue I was trying to avoid. Didn't think about print statements though ...

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12403>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:55:34 2011
From: report at bugs.python.org (mouad)
Date: Sat, 25 Jun 2011 14:55:34 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1309013734.93.0.657292710043.issue12157@psf.upfronthosting.co.za>


mouad <mouadino at gmail.com> added the comment:

The test case use a helper function in test/support.py that i have proposed in issue #12410.

I'm dropping this comment here because i don't have the rights to edit the issue dependency.

cheers;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12157>
_______________________________________

From report at bugs.python.org  Sat Jun 25 16:58:26 2011
From: report at bugs.python.org (mouad)
Date: Sat, 25 Jun 2011 14:58:26 +0000
Subject: [issue12410] Create a new helper function that enable to test that an
	operation don't hang more than a given timeout.
In-Reply-To: <1309013375.96.0.63412212065.issue12410@psf.upfronthosting.co.za>
Message-ID: <1309013906.04.0.306761083661.issue12410@psf.upfronthosting.co.za>


Changes by mouad <mouadino at gmail.com>:


Removed file: http://bugs.python.org/file22467/operation_timeout.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12410>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:00:06 2011
From: report at bugs.python.org (mouad)
Date: Sat, 25 Jun 2011 15:00:06 +0000
Subject: [issue12410] Create a new helper function that enable to test that an
	operation don't hang more than a given timeout.
In-Reply-To: <1309013375.96.0.63412212065.issue12410@psf.upfronthosting.co.za>
Message-ID: <1309014006.7.0.929423447758.issue12410@psf.upfronthosting.co.za>


Changes by mouad <mouadino at gmail.com>:


Added file: http://bugs.python.org/file22469/operation_timeout.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12410>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:01:24 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Jun 2011 15:01:24 +0000
Subject: [issue12296] Minor clarification in devguide
In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>
Message-ID: <1309014084.97.0.792132336398.issue12296@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

(this obviously does not apply to new classes, functions or *optional* arguments) ?

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12296>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:04:36 2011
From: report at bugs.python.org (Michael Foord)
Date: Sat, 25 Jun 2011 15:04:36 +0000
Subject: [issue11763] assertEqual memory issues with large text inputs
In-Reply-To: <1301948164.44.0.0206798295308.issue11763@psf.upfronthosting.co.za>
Message-ID: <1309014276.45.0.529410323543.issue11763@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

The basic idea of the patch is good, but instead of introducing _MAX_LENGTH, maxDiff should be reused.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11763>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:07:34 2011
From: report at bugs.python.org (Michael Foord)
Date: Sat, 25 Jun 2011 15:07:34 +0000
Subject: [issue11763] assertEqual memory issues with large text inputs
In-Reply-To: <1301948164.44.0.0206798295308.issue11763@psf.upfronthosting.co.za>
Message-ID: <1309014454.3.0.449241394516.issue11763@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Sorry, ignore that. I see that the patch already passes maxDiff to truncate_str.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11763>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:09:08 2011
From: report at bugs.python.org (Jonas Wagner)
Date: Sat, 25 Jun 2011 15:09:08 +0000
Subject: [issue12411] cgi.parse_multipart is broken on 3.x
In-Reply-To: <1309014548.2.0.906650270303.issue12411@psf.upfronthosting.co.za>
Message-ID: <1309014548.2.0.906650270303.issue12411@psf.upfronthosting.co.za>


New submission from Jonas Wagner <veers at gmx.ch>:

While writing tests for the cgi module I came across what looks like a conversion bug.

cgi.parse_multipart is comparing values it reads from a binary file like with a string literal:
line = fp.readline()
...
if line.startswith("--"):

This patch adds fixes the issue and adds test for it.

----------
components: Library (Lib)
files: cgi-coverage.diff
keywords: patch
messages: 139082
nosy: jonas.wagner
priority: normal
severity: normal
status: open
title: cgi.parse_multipart is broken on 3.x
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file22470/cgi-coverage.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12411>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:15:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 15:15: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: <E1QaUZX-0002yt-6A@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 11568c59d9d4 by Raymond Hettinger in branch '2.7':
Issue 11802:  filecmp cache was growing without bound.
http://hg.python.org/cpython/rev/11568c59d9d4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:15:10 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Jun 2011 15:15:10 +0000
Subject: [issue11233] clarifying Availability: Unix
In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>
Message-ID: <1309014910.09.0.808711153.issue11233@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
Removed message: http://bugs.python.org/msg130754

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11233>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:15:47 2011
From: report at bugs.python.org (Giovanni Bajo)
Date: Sat, 25 Jun 2011 15:15:47 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1309014947.24.0.941872043265.issue6721@psf.upfronthosting.co.za>


Giovanni Bajo <giovannibajo at gmail.com> added the comment:

If there's agreement that the general problem is unsolvable (so fork and threads just don't get along with each other), what we could attempt is trying to limit the side effects in the standard library, so that fewest users as possible are affected by this problem.

For instance, having deadlocks just because of print statements sounds like a bad QoI that we could attempt to improve. Is there a reason while BufferedIO needs to hold its internal data-structure lock (used to make it thread-safe) while it's doing I/O and releasing the GIL? I would think that it's feasible to patch it so that its internal lock is only used to synchronize accesses to the internal data structures, but it is never held while I/O is performed (and thus the GIL is released -- at which point, if another threads forks, the problem appears).

----------
nosy: +Giovanni.Bajo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:16:37 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Jun 2011 15:16:37 +0000
Subject: [issue12411] cgi.parse_multipart is broken on 3.x
In-Reply-To: <1309014548.2.0.906650270303.issue12411@psf.upfronthosting.co.za>
Message-ID: <1309014997.03.0.960725501111.issue12411@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12411>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:18:31 2011
From: report at bugs.python.org (=?utf-8?b?VG9tYcW+IMWgb2xj?=)
Date: Sat, 25 Jun 2011 15:18:31 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1309015111.35.0.215728367073.issue6721@psf.upfronthosting.co.za>


Changes by Toma? ?olc <tomaz.solc at tablix.org>:


----------
nosy: +avian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:21:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 15:21:29 +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: <E1QaUfo-0003PV-AS@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2bacaf6a80c4 by Raymond Hettinger in branch '3.2':
Issue 11802:  filecmp cache was growing without bound.
http://hg.python.org/cpython/rev/2bacaf6a80c4

New changeset 8f4466619e1c by Raymond Hettinger in branch 'default':
Issue 11802:  filecmp cache was growing without bound.
http://hg.python.org/cpython/rev/8f4466619e1c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:24:50 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Jun 2011 15:24: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: <1309015490.85.0.331046306983.issue11802@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Made a simple fix to keep the cache from growing without bound.
Leaving this open for 3.3 as a feature request to implement a more sophisticated strategy using file hashes or somesuch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:29:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Jun 2011 15:29:32 +0000
Subject: [issue12341] Some additions to .hgignore
In-Reply-To: <1308156137.45.0.893152397766.issue12341@psf.upfronthosting.co.za>
Message-ID: <1309015772.83.0.958881327884.issue12341@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Please backport.

----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12341>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:39:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 15:39:00 +0000
Subject: [issue12341] Some additions to .hgignore
In-Reply-To: <1308156137.45.0.893152397766.issue12341@psf.upfronthosting.co.za>
Message-ID: <E1QaUwl-0004Rb-6m@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ef306bd1d122 by Ezio Melotti in branch 'default':
#12341: add coverage files/dirs to .hgignore. Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/ef306bd1d122

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12341>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:39:27 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Jun 2011 15:39:27 +0000
Subject: [issue12410] Create a new helper function that enable to test that an
	operation don't hang more than a given timeout.
In-Reply-To: <1309013375.96.0.63412212065.issue12410@psf.upfronthosting.co.za>
Message-ID: <1309016367.17.0.34895097462.issue12410@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12410>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:39:59 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 25 Jun 2011 15:39:59 +0000
Subject: [issue12341] Some additions to .hgignore
In-Reply-To: <1308156137.45.0.893152397766.issue12341@psf.upfronthosting.co.za>
Message-ID: <1309016399.55.0.104384674163.issue12341@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed during the EuroPython sprint, thanks for the patch!

----------
nosy: +ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12341>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:54:50 2011
From: report at bugs.python.org (Francisco Garcia)
Date: Sat, 25 Jun 2011 15:54:50 +0000
Subject: [issue12412] non defined representation for pwd.struct_passwd
In-Reply-To: <1309017290.05.0.556727126165.issue12412@psf.upfronthosting.co.za>
Message-ID: <1309017290.05.0.556727126165.issue12412@psf.upfronthosting.co.za>


New submission from Francisco Garcia <public at francisco-garcia.net>:

pwd.struct_passwd has different representations in cpython 2.7.2 and pypy 1.5

A unit test from cpython might enforce the same representation across interpreters:

>>> print pwd.getpwuid(os.getuid())

Current cpython output:

pwd.struct_passwd(pw_name='demo_user', pw_passwd='********', pw_uid=1001, pw_gid=100, pw_gecos='demo_user', pw_dir='/Users/demo_user', pw_shell='/bin/bash')

Current pypy output
('demo_user', '********', 1001, 100, 'demo_user', '/Users/demo_user', '/bin/bash')

----------
messages: 139090
nosy: fgarciar
priority: normal
severity: normal
status: open
title: non defined representation for pwd.struct_passwd
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12412>
_______________________________________

From report at bugs.python.org  Sat Jun 25 17:59:03 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 25 Jun 2011 15:59:03 +0000
Subject: [issue12410] Create a new helper function that enable to test that an
	operation don't hang more than a given timeout.
In-Reply-To: <1309013375.96.0.63412212065.issue12410@psf.upfronthosting.co.za>
Message-ID: <1309017543.71.0.579565358621.issue12410@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

It's a little bit more complicated than that:
- signals and threads don't mix well together
- this will make syscalls fail with EINTR
- the old SIGALRM handler is lost
- etc

In short, don't use signals.
I'm not sure there's a reliable way to write such a general-purpose wrapper (usually one can use select() with a timeout or spawn a subprocess and use communicate's timeout to achieve this kind of things).
In your use case (issue #12157), I think that letting the test block is fine, since:
- there's no easy way to add a timeout (but you could spawn a new interpreter and use communicate with a timeout if you really wanted to)
- it will be caught by the faulthandler module
- a test killed by faulthandler's timeout is more interesting to fix that a "common" failed test ;-)

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12410>
_______________________________________

From report at bugs.python.org  Sat Jun 25 18:05:24 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Jun 2011 16:05:24 +0000
Subject: [issue11669] Clarify Lang Ref "Compound statements" footnote
In-Reply-To: <1301042574.67.0.975748752077.issue11669@psf.upfronthosting.co.za>
Message-ID: <1309017924.91.0.553348245756.issue11669@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Just to make explicit what's happening:


>>> try:
...     try:
...         raise TypeError()
...     finally:
...         raise ValueError()
... except TypeError as e:
...     print('mmm')
... 
Traceback (most recent call last):
  File "<stdin>", line 3, in <module>
TypeError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 5, in <module>
ValueError

while


>>> try:
...     try:
...         raise TypeError()
...     finally:
...         raise ValueError()
... except ValueError as e:
...     print ('mmm')
... 
mmm

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11669>
_______________________________________

From report at bugs.python.org  Sat Jun 25 18:05:54 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Jun 2011 16:05:54 +0000
Subject: [issue11669] Clarify Lang Ref "Compound statements" footnote
In-Reply-To: <1301042574.67.0.975748752077.issue11669@psf.upfronthosting.co.za>
Message-ID: <1309017954.46.0.308974663786.issue11669@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Ok, I send it too soon... attached is a patch to fix this bug (it applies on default, 3.2 and 2.7).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11669>
_______________________________________

From report at bugs.python.org  Sat Jun 25 18:06:18 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Jun 2011 16:06:18 +0000
Subject: [issue11669] Clarify Lang Ref "Compound statements" footnote
In-Reply-To: <1301042574.67.0.975748752077.issue11669@psf.upfronthosting.co.za>
Message-ID: <1309017978.85.0.29821870039.issue11669@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
keywords:  -needs review
Added file: http://bugs.python.org/file22471/issue11669-default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11669>
_______________________________________

From report at bugs.python.org  Sat Jun 25 18:15:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Jun 2011 16:15:58 +0000
Subject: [issue12412] non defined representation for pwd.struct_passwd
In-Reply-To: <1309017290.05.0.556727126165.issue12412@psf.upfronthosting.co.za>
Message-ID: <1309018558.22.0.371739033479.issue12412@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looks like the difference between a regular tuple and a named tuple.  The correct test is to access the members using the names, and the test suite currently does this.  The repr shouldn't, I think, be required to be identical.

On the other hand, if pypy is implementing named tuples and the repr doesn't include the names, perhaps there is a missing test in the tests of named tuples.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12412>
_______________________________________

From report at bugs.python.org  Sat Jun 25 18:17:26 2011
From: report at bugs.python.org (engelbert gruber)
Date: Sat, 25 Jun 2011 16:17:26 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1309018646.11.0.292423225972.issue12291@psf.upfronthosting.co.za>


engelbert gruber <grubert at users.sourceforge.net> added the comment:

patch to test_marshal.py that obviously fails in current implementation.

IMHO is file might not be seekable one can not cache so maybe do not do it.

----------
nosy: +grubert
Added file: http://bugs.python.org/file22472/multiple_dump_load_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sat Jun 25 18:19:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Jun 2011 16:19:25 +0000
Subject: [issue12374] Execution model should explain compile vs definition vs
	execution time
In-Reply-To: <1308582911.55.0.701954968644.issue12374@psf.upfronthosting.co.za>
Message-ID: <1309018765.69.0.294689091113.issue12374@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You could try the mentors list or Doug Hellman's volunteer group, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12374>
_______________________________________

From report at bugs.python.org  Sat Jun 25 18:23:21 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Jun 2011 16:23:21 +0000
Subject: [issue12403] Mention sys.displayhook in code module docs and the
	compile builtin docs
In-Reply-To: <1308959744.93.0.261089879651.issue12403@psf.upfronthosting.co.za>
Message-ID: <1309019001.11.0.366260847336.issue12403@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, sys.stdout and sys.stderr don't have to be real file objects.  You could substitute a file-like object (one that implements the methods that get called during the interpretation loop) that does your multiplexing.  That kind of trick is one of the things that makes Python so much fun to work with :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12403>
_______________________________________

From report at bugs.python.org  Sat Jun 25 18:24:56 2011
From: report at bugs.python.org (Dave King)
Date: Sat, 25 Jun 2011 16:24:56 +0000
Subject: [issue975330] Inconsistent newline handling in email module
Message-ID: <1309019096.44.0.373777379089.issue975330@psf.upfronthosting.co.za>


Dave King <dave at davbo.org> added the comment:

Added some tests against the patch provided by R. David Murray. See attached patch.

Tests pass against default.

----------
nosy: +davbo
Added file: http://bugs.python.org/file22473/base_encode_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue975330>
_______________________________________

From report at bugs.python.org  Sat Jun 25 18:37:24 2011
From: report at bugs.python.org (mouad)
Date: Sat, 25 Jun 2011 16:37:24 +0000
Subject: [issue12410] Create a new helper function that enable to test that an
	operation don't hang more than a given timeout.
In-Reply-To: <1309013375.96.0.63412212065.issue12410@psf.upfronthosting.co.za>
Message-ID: <1309019844.01.0.354999303702.issue12410@psf.upfronthosting.co.za>


mouad <mouadino at gmail.com> added the comment:

Thanks for the instructive feedback :)

I totally agree i guess there is a lot of issues that i didn't think of :-(, my first thinking was to use "Pool.join" timeout argument but it was removed in 3.2 (by the way i didn't find the issue or the rational that lead to this change).

And now that i know about "faulthandler" module i guess that will make also my life easier :), i will rewrite the patch in the issue #12157 to not use any *fancy* way to check if it will hang.

cheers,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12410>
_______________________________________

From report at bugs.python.org  Sat Jun 25 18:37:52 2011
From: report at bugs.python.org (Stefan Schwarzer)
Date: Sat, 25 Jun 2011 16:37: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: <1309019872.55.0.743837456138.issue4608@psf.upfronthosting.co.za>


Stefan Schwarzer <sschwarzer at users.sourceforge.net> added the comment:

It turned out that although the addinfourl instance had the `__iter__` attribute in `addbase.__init__` correctly assigned, `__iter__` wasn't found by the `iter` builtin. It seems that `iter` always tries to use the `__iter__` method of the _class_ and doesn't look at the instance.

Riccardo Attilio Galli and I made the attached patch. The patch also fixes a corresponding `TypeError` for "file://" URLs, not just "ftp://" URLs.

----------
nosy: +sschwarzer
Added file: http://bugs.python.org/file22474/issue4608.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4608>
_______________________________________

From report at bugs.python.org  Sat Jun 25 18:44:24 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Jun 2011 16:44: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: <1309020264.75.0.174757409192.issue4608@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: flox -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4608>
_______________________________________

From report at bugs.python.org  Sat Jun 25 18:46:42 2011
From: report at bugs.python.org (mouad)
Date: Sat, 25 Jun 2011 16:46:42 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1309020402.21.0.107971221041.issue12157@psf.upfronthosting.co.za>


Changes by mouad <mouadino at gmail.com>:


Added file: http://bugs.python.org/file22475/issue-12157.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12157>
_______________________________________

From report at bugs.python.org  Sat Jun 25 18:48:57 2011
From: report at bugs.python.org (mouad)
Date: Sat, 25 Jun 2011 16:48:57 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1309020537.74.0.716502318135.issue12157@psf.upfronthosting.co.za>


mouad <mouadino at gmail.com> added the comment:

Here is a new patch that in the opposite of the first one, it don't try to check if the pool.join() will hang or no, after a discussion with neologix in issue #12410 .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12157>
_______________________________________

From report at bugs.python.org  Sat Jun 25 19:10:04 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 25 Jun 2011 17:10:04 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308654176.69.0.733792484541.issue12352@psf.upfronthosting.co.za>
Message-ID: <BANLkTikTDeHUxsKP_UCn13sYFjqm0PMqeg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Patch (with test) attached. It disables the garbage collector inside
critical sections.
Of course, if another thread re-enables the gc while the current
thread is inside a critical section, things can break (the probability
is really low, but who knows).
I can't think of any satisfying solution, since it's tricky, because
we don't want it to be thread-safe but reentrant, which is much more
difficult.
I've got another patch which does the following:
- in free(), perform a trylock of the mutex
- if the trylock fails, then create a new Finalizer to postpone the
freeing of the same block to a later time, when the gc is called
- the only problem is that I have to build a dummy reference cycle to
pass it to Finalize if I want free() to be called by the GC later (and
not when the object's reference count drops to 0, otherwise we would
get an infinite recursion).

Another solution would be to make the Finalizer callback run lockless,
maybe just set add the block number to a list/set, and perform the
freeing of pending blocks synchronously when malloc() is called (or
the heap is finalized). There are two drawbacks to that:
- adding an element to a set is not guaranteed to be thread-safe
(well, it is under cPython because of the GIL)
- freeing blocks synchronously means that the blocks won't be freed
until malloc() is called (which could be never)

Suggestions welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Sat Jun 25 19:10:24 2011
From: report at bugs.python.org (sorin)
Date: Sat, 25 Jun 2011 17:10:24 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1309021824.57.0.469134753963.issue12398@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

You are right, I debugged the problem a little more and discovered at least one bug in PyAMF.

Still, I was surprised to find out something very strange, it look that BytesIO.getvalue() does return `str` even if the documentation says it does return `bytes`. Should I file another bug?

Python 2.7.1 (r271:86832, Jun 13 2011, 14:28:51) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import io
>>> a = io.BytesIO()
>>> a
<_io.BytesIO object at 0x10f9453b0>
>>> a.getvalue()
''
>>> print type(a.getvalue())
<type 'str'>
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12398>
_______________________________________

From report at bugs.python.org  Sat Jun 25 19:10:47 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 25 Jun 2011 17:10:47 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1309021847.59.0.499393950149.issue12352@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22476/heap_gc_deadlock.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Sat Jun 25 19:16:20 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Sat, 25 Jun 2011 17:16:20 +0000
Subject: [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=PVUrEKHD4ri2XAUSd3a_cfxs6xA@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

-1

> Hi! We have the devguide now, and it should be the place where to look
> for references and docs about contributing to Python, that means also
> for the documentation.

For information specific to the Python documentation itself, but not
relevant to users documenting their own projects, yes.

> In the official Python doc we have a section "Documenting Python"
> (http://docs.python.org/py3k/documenting/index.html) and I think it
> should be merged into the devguide - what's your opinion on that?

The scope of this document is much larger than Python's documentation,
but extends to all projects written in Python that use Sphinx as their
documentation tool.  With that, it makes sense to keep it as part of
the documentation for users of Python.

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12409>
_______________________________________

From report at bugs.python.org  Sat Jun 25 19:16:52 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 25 Jun 2011 17:16:52 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1309022212.27.0.235192907787.issue12352@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22476/heap_gc_deadlock.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Sat Jun 25 19:17:21 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 25 Jun 2011 17:17:21 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1309022241.75.0.362011633051.issue12352@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file22477/heap_gc_deadlock.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Sat Jun 25 19:31:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jun 2011 17:31:12 +0000
Subject: [issue12341] Some additions to .hgignore
In-Reply-To: <1308156137.45.0.893152397766.issue12341@psf.upfronthosting.co.za>
Message-ID: <E1QaWhK-0007kq-QD@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ee9eb4e05180 by Ezio Melotti in branch '2.7':
#12341: add coverage files/dirs to .hgignore. Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/ee9eb4e05180

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12341>
_______________________________________

From report at bugs.python.org  Sat Jun 25 19:39:56 2011
From: report at bugs.python.org (Stephen Thorne)
Date: Sat, 25 Jun 2011 17:39:56 +0000
Subject: [issue10510] distutils upload/register should use CRLF in HTTP
	requests
In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za>
Message-ID: <1309023596.39.0.0553485352238.issue10510@psf.upfronthosting.co.za>


Stephen Thorne <stephen at thorne.id.au> added the comment:

Okay, I looked at this, then I ran into str/byte type problems with the email module. Will wait until 'email' is sorted out before I consider a ticket like this one again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Sat Jun 25 20:26:37 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Jun 2011 18:26:37 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1309026397.52.0.453790531508.issue12398@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No, that's correct.  In python 2.x the 'bytes' stuff is just a portability aid.  In 2.x, bytes and string are the same type.  In Python 3 they aren't, so by using the 'fake' classes in python2 you can often make your code work correctly on both python2 and python3.

So, can this issue be closed, or do you think there is still might be a valid backward compatibility issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12398>
_______________________________________

From report at bugs.python.org  Sat Jun 25 20:31:39 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jun 2011 18:31:39 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1309026699.59.0.537268578618.issue12398@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In 2.7, bytes is an alias for str to aid porting to 3.x.
>>> bytes is str
True
>>> type(bytes())
<type 'str'>

I suspect the doc uses 'bytes' rather than 'str' because it was backported from 3.x. Perhaps it should be changed but I do not know the policy on using the alias in 2.6/7 docs.

I presume in 2.7 io.BytesIO is similar, if not equivalent to io.StringIO, but it is not an alias. Again, it was added so 2.7 code could use a bytes memory buffer that would remain bytes in 3.x and not become unicode text, like StringIO does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12398>
_______________________________________

From report at bugs.python.org  Sat Jun 25 21:49:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Jun 2011 19:49:48 +0000
Subject: [issue10510] packaging upload/register should use CRLF in HTTP
	requests
In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za>
Message-ID: <1309031388.24.0.906100811372.issue10510@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I'm having a look at this ticket now. It looks like this can be
> rewritten to use common code

Indeed!  As such, I?m folding this feature request into #12169, which has a patch under review.

----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> Factor out common code for d2 commands register, upload and upload_docs
title: distutils upload/register should use CRLF in HTTP requests -> packaging upload/register should use CRLF in HTTP requests

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Sat Jun 25 21:54:24 2011
From: report at bugs.python.org (sorin)
Date: Sat, 25 Jun 2011 19:54:24 +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: <1309031664.1.0.864654468055.issue11898@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

I have to add some details here. First, this bug has nothing to do with the URL, it does reproduce for normal urls.


Still the problem with the line: "msg += message_body" is quite complex when combined with Python 2.7:

type(msg) is unicode
type(message_body) is str ... even if I tried to manually force Python for use bytes. It seams that in 2.7 bytes are alias to str. Due to this the code will fail to run only on 2.7 because it will try to convert  binary data to unicode string.

If I am not mistaken the code will work with Python 3.x, because there bytes() are not str().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Sat Jun 25 21:57:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Jun 2011 19:57:10 +0000
Subject: [issue12169] Factor out common code for d2 commands register,
	upload and upload_docs
In-Reply-To: <1306255725.22.0.23750798807.issue12169@psf.upfronthosting.co.za>
Message-ID: <1309031830.44.0.557554061941.issue12169@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I made some comments on the code review site; maybe you didn?t get the email, there is a known bug about that.  You can follow the ?review? link on the right of the patch file to see it.

I have closed #10510, which asked that HTTP request use CRLF for maximum compatibility.  The current patch does it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12169>
_______________________________________

From report at bugs.python.org  Sat Jun 25 22:02:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Jun 2011 20:02:22 +0000
Subject: [issue5572] packaging should respect the LIBS configure env var
In-Reply-To: <1238095013.07.0.627782689433.issue5572@psf.upfronthosting.co.za>
Message-ID: <1309032142.82.0.80854195782.issue5572@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The distutils feature freeze doesn?t let us accept this patch, but there is definite value for packaging, so I will port it.  Thanks for the original patch!

----------
resolution: wont fix -> 
status: closed -> open
title: distutils ignores the LIBS configure env var -> packaging should respect the LIBS configure env var

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5572>
_______________________________________

From report at bugs.python.org  Sat Jun 25 22:07:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Jun 2011 20:07:21 +0000
Subject: [issue12296] Minor clarification in devguide
In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>
Message-ID: <1309032441.35.0.584406187504.issue12296@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Good idea.  So, any -1 on this:

(this obviously does not apply to new classes or functions, or new optional arguments)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12296>
_______________________________________

From report at bugs.python.org  Sat Jun 25 22:10:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Jun 2011 20:10:12 +0000
Subject: [issue10020] docs for sqlite3 describe functions not available
	without recompiling
In-Reply-To: <1286124753.24.0.309036392806.issue10020@psf.upfronthosting.co.za>
Message-ID: <1309032612.7.0.662563656948.issue10020@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/issue10020>
_______________________________________

From report at bugs.python.org  Sat Jun 25 22:13:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Jun 2011 20:13:08 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1309032788.36.0.202230173435.issue11104@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your work.  I will make a final test and review and commit it in the coming days.  I?ll adapt the versionchanged text, since I won?t commit this in 3.1 (in security mode now, not bugfix mode).

----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11104>
_______________________________________

From report at bugs.python.org  Sat Jun 25 22:17:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Jun 2011 20:17:38 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1309033058.5.0.278175221928.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Perhaps some mechanism needs to be provided to indicate additional
> processing options per script line:

Sure.  Higery will have to examine existing usage and think about setuptools?packaging transition.  We?ll start simple and easy (in other words, with something very similar to setuptools) and expand from that.

>> Version independence always means version independence in the same
>> major line of development (i.e. X number in X.Y.Z), or to put it
>> another way, version independence among the versions listed as
>> supported in the Trove classifiers.
> That can still be a problem with e.g. byte literals: 2.5 will raise
> SyntaxError where 2.6, 2.7 will not.

If the code is compatible with 2.6+ only, the ?2.5? Trove classifier should not be used.  (Maybe I?m misunderstanding your point.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Sat Jun 25 22:20:01 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 25 Jun 2011 20:20:01 +0000
Subject: [issue5572] packaging should respect the LIBS configure env var
In-Reply-To: <1238095013.07.0.627782689433.issue5572@psf.upfronthosting.co.za>
Message-ID: <1309033201.4.0.104929268461.issue5572@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/issue5572>
_______________________________________

From report at bugs.python.org  Sat Jun 25 22:22:42 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 25 Jun 2011 20:22:42 +0000
Subject: [issue11898] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1309031664.1.0.864654468055.issue11898@psf.upfronthosting.co.za>
Message-ID: <20110625202238.GA10432@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hi Sorin,
On Sat, Jun 25, 2011 at 07:54:24PM +0000, sorin wrote:
> type(message_body) is str ... even if I tried to manually force
> Python for use bytes. It seams that in 2.7 bytes are alias to str.
> Due to this the code will fail to run only on 2.7 because it will
> try to convert  binary data to unicode string.

Bit confused here. You encode the string to bytes and decode it back
to str. One does not force bytes to str. And if you use, str or bytes
consistently in Python2.7 you wont face the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Sat Jun 25 22:38:04 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 25 Jun 2011 20:38:04 +0000
Subject: [issue12255] A few changes to .*ignore
In-Reply-To: <1307119345.93.0.971452096543.issue12255@psf.upfronthosting.co.za>
Message-ID: <1309034284.2.0.0707523549856.issue12255@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Eric, sure go ahead. As I am not affected by remains of .rej and .orig (neither have I found their usefulness (yet)), so my concerns can be stepped over. Plus, I have found a way to ignore files via patterns in .hgrc.

I already see you and RDM proposing the change, so I am okay to follow. But if you think discussion in python-dev or python-committers would be helpful it would be a good idea, because it affects people's working environment and some might have some concerns or ideas (which might be helpful).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12255>
_______________________________________

From report at bugs.python.org  Sat Jun 25 22:53:25 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Jun 2011 20:53:25 +0000
Subject: [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1309035205.73.0.306835457711.issue12409@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Fred, thanks for your input! Let's see what others think, but I think that at the very least, the "Building the documentation" section (that seams very specific to python) should be moved into the devguide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12409>
_______________________________________

From report at bugs.python.org  Sat Jun 25 22:59:39 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 25 Jun 2011 20:59:39 +0000
Subject: [issue5572] packaging should respect the LIBS configure env var
In-Reply-To: <1238095013.07.0.627782689433.issue5572@psf.upfronthosting.co.za>
Message-ID: <1309035579.53.0.782609965285.issue5572@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Collin, I'm sure that you could use LDFLAGS instead LIBS to boost python. If I remember well this require set_executables to be commented in setup.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5572>
_______________________________________

From report at bugs.python.org  Sat Jun 25 23:25:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jun 2011 21:25:28 +0000
Subject: [issue12296] Minor clarification in devguide
In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>
Message-ID: <1309037128.91.0.344093955875.issue12296@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The parenthetical comment is a complete sentence, and no longer trivial. I would separate it and write it more simply as
"... their code. (This obviously does not apply to new classes, functions, or optional arguments.)"

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12296>
_______________________________________

From report at bugs.python.org  Sat Jun 25 23:50:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Jun 2011 21:50:25 +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: <1309038625.09.0.252549878861.issue11870@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Victor: to debug this kind of problem, it would be great
> if faulthandler could also dump tracebacks of children processes.
> Do you mind if I create a new issue?

Please open a new issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11870>
_______________________________________

From report at bugs.python.org  Sat Jun 25 23:55:11 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 25 Jun 2011 21:55:11 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1309038911.2.0.0172513234671.issue12394@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> If the code is compatible with 2.6+ only, the ?2.5? Trove classifier should not be used.  (Maybe I?m misunderstanding your point.)

I was referring to your comment about the X in X.Y.Z. We also need to bear in mind that you sometimes just get trove classifiers ending in ":: Python :: 2", with no more specific version information. (Of course, there can be a check for this, with perhaps an installation-time warning.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Sat Jun 25 23:56:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Jun 2011 21:56:47 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1309039007.43.0.407403239456.issue12157@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/issue12157>
_______________________________________

From report at bugs.python.org  Sun Jun 26 00:09:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Jun 2011 22:09:31 +0000
Subject: [issue12410] Create a new helper function that enable to test that an
	operation don't hang more than a given timeout.
In-Reply-To: <1309013375.96.0.63412212065.issue12410@psf.upfronthosting.co.za>
Message-ID: <1309039771.74.0.357591759355.issue12410@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

alarm() is one possible implementation, but Charles-Fran?ois listed some drawbacks.

You can also use resource.setrlimit(RLIMIT_CPU), but the timeout is the CPU time (e.g. you cannot stop a sleep) and it is not portable (e.g. resource is not available on Windows).

Another possible implementation is a thread. faulthandler uses an "hidden" thread (implemented in C): a thread ignoring all signals using pthread_sigmask. Python threads are not reliable for a timeout because of the GIL, and it is not easy to "interrupt" another thread from the "timeout" thread. For example, you cannot (easily) raise an exception in another thread.

> I'm not sure there's a reliable way to write such a general-purpose
> wrapper

I agree, but it doesn't mean that it is not possible :-)

I think that you should try to implement in C a thread ignoring all signals. It becomes more complex when you have to implement the "interrupt the current thread" (current thread, or maybe the thread using the operation_timeout context manager?) part.

I suppose that you will have to use low-level "tricks" and you will have to experiment your tool on different platform.

You should start this project outside CPython (as a third party module), and then ask for an integration when your work is well tested. You have to know that a module "dies" when it enters CPython: you have to wait something like 18 months to modify it, so you have to be sure that your code is "correct" ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12410>
_______________________________________

From report at bugs.python.org  Sun Jun 26 00:19:26 2011
From: report at bugs.python.org (Michael Grazebrook)
Date: Sat, 25 Jun 2011 22:19:26 +0000
Subject: [issue11163] iter() documentation code doesn't work
In-Reply-To: <1309005538.02.0.543346836936.issue11163@psf.upfronthosting.co.za>
Message-ID: <4E065EEB.3070200@grazebrook.com>


Michael Grazebrook <michael at grazebrook.com> added the comment:

Thank you.

On 25/06/2011 13:38, Raymond Hettinger wrote:
> 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/issue11163>
> _______________________________________
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1388 / Virus Database: 1513/3725 - Release Date: 06/25/11
>
>
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11163>
_______________________________________

From report at bugs.python.org  Sun Jun 26 00:31:00 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jun 2011 22:31:00 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1309041060.97.0.0711730308103.issue12157@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The patch to the multiprocessing code is trivial:
+            del cache[self._job]

The difference in tests is
+        with test.support.operation_timeout(5):
+            p.join()
versus
+        p.join()

Victor, do you agree with the simpler method, depending on faulthandler to catch a hang in the test and fail it? Or is the explicit timeout better?

----------
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12157>
_______________________________________

From report at bugs.python.org  Sun Jun 26 00:31:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Jun 2011 22:31:45 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1309041105.1.0.332769384161.issue12352@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Or you can combine your two ideas:

> in free(), perform a trylock of the mutex
> if the trylock fails, then create a new Finalizer to postpone the
freeing of the same block to a later time,...
> ... perform the freeing of pending blocks synchronously
> when malloc() is called

If free() is called indirectly from malloc() (by the garbage collector), free() adds the block to free in a "pending free" list. Pseudo code:

-----------------------
def __init__(self):
  ...
  self._pending_free = queue.Queue()

def _exec_pending_free(self):
  while True:
    try:
      block = self._pending_free.get_nowait()
    except queue.Empty:
      break
    self._free(block)

def free(self, block):
  if self._lock.acquire(False):
     self._exec_pending_free()
     self._free(block)
  else:
     #?malloc holds the lock
     self._pending_free.append(block)

def malloc():
  with self._lock:
    self._malloc()
    self._exec_pending_free()
-----------------------

Problem: if self._pending_free.append() appends whereas malloc() already exited, the free will have to wait until the next call to malloc() or free(). I don't know if this case (free() called while malloc() is running, but malloc() exits before free()) really occur: this issue is a deadlock because free() is "called" from malloc(), and so malloc() waits until the free() is done. It might occur if the garbage collector calls free after _exec_pending_free() but before releasing the lock.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Sun Jun 26 00:39:57 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jun 2011 22:39:57 +0000
Subject: [issue7365] grp and pwd should treat uid and gid as unsigned
In-Reply-To: <1258680245.88.0.627899346962.issue7365@psf.upfronthosting.co.za>
Message-ID: <1309041597.85.0.56537310371.issue7365@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7365>
_______________________________________

From report at bugs.python.org  Sun Jun 26 00:46:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Jun 2011 22:46:28 +0000
Subject: [issue12410] Create a new helper function that enable to test that an
	operation don't hang more than a given timeout.
In-Reply-To: <1309013375.96.0.63412212065.issue12410@psf.upfronthosting.co.za>
Message-ID: <1309041988.87.0.291582600397.issue12410@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, there is another possible implementation: use a subprocess. But if the timeout is implemented using a subprocess, the syntax cannot be:

with timeout(5):
   do_something()

It should be something like:


timeout(5, """if 1:
   import os, sys
   ...
   do_something()
   ...
   sys.exit(0)
""")

Some tests are already doing that manually.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12410>
_______________________________________

From report at bugs.python.org  Sun Jun 26 01:02:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Jun 2011 23:02:01 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1309042921.78.0.202359526463.issue12157@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

>Don't Try to use any fancy way to check if the join will hang,
> leave all the job to faulthandler.	

> Victor, do you agree with the simpler method, depending
> on faulthandler to catch a hang in the test and fail it?
> Or is the explicit timeout better?

If the patch fixes the hang, there is no good reason to write code to handle a new hang.

We have generic "watchdogs":

 - buildbot timeout (any Python version)
 - regrtest timeout implemented using faulthandler (only in Python 3.x)

If you run directly the .py test file on a command line, you can still use CTRL+c or CTRL+z to interrupt / stop the process.

You may want to improve these generic watchdogs, but write a specific watchdog for one specific test function looks useless to me.

Remember that timeouts are not reliable: we have sometimes false failures because of very slow buildbots... For regrtest timeout, I tried 10, 15, 20 and 30 minutes before choosing a timeout of 60 minutes. For lower values, we have many false failures.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12157>
_______________________________________

From report at bugs.python.org  Sun Jun 26 01:23:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Jun 2011 23:23:06 +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: <1309044186.09.0.6544119535.issue11870@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

+    @unittest.skipIf(sys.platform in ('freebsd4', 'freebsd5', 'freebsd6',
+                     'netbsd5', 'os2emx'), "due to known OS bug")

This skip gives very few information, and it is duplicated for each function. I would prefer a constant of the "broken OSes" with your following comment attached to the constant:

+    # Between fork() and exec(), only async-safe functions are allowed (issues
+    # #12316 and #11870), and fork() from a worker thread is known to trigger
+    # problems with some operating systems: skip problematic tests on platforms
+    # known to behave badly.

Or split the test case into two testcases: one using fork and skipped on broken platforms, one not using fork?

---

> As for test_3_join_in_forked_from_thread, well, it could be more
> or less the same problem. We're really doing something prohibited
> by POSIX, so things might break in unexpected ways.

If the creation of a thread after a fork is reliable on some systems, we should not deny the creation of new threads after a fork. You can replace "creation of new threads" by any other non async-safe function in my previous sentence. Therefore I agree that the good answer to this issue is to skip the test on "broken systems" (or should we call them "POSIX compliant systems?" :-)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11870>
_______________________________________

From report at bugs.python.org  Sun Jun 26 01:33:18 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 25 Jun 2011 23:33:18 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1309041105.1.0.332769384161.issue12352@psf.upfronthosting.co.za>
Message-ID: <BANLkTimXSSB7fEg2gS5FgDamSh71ZS+SbA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

[...]
> def free(self, block):
> ?if self._lock.acquire(False):
> ? ? self._exec_pending_free()
> ? ? self._free(block)
> ?else:
> ? ? #?malloc holds the lock
> ? ? self._pending_free.append(block)
>

_pending_free uses a lock internally to make it thread-safe, so I
think this will have exactly the same problem (the trylock can fail in
case of contention or free() from multiple threads, thus we can't be
sure that the else clause is executed on behalf of the garbage
collector and it won't run while we're adding the block to
_pending_free).

Anyway, this seems complicated and error-prone, disabling the gc seems
the most straightforward way to handle that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Sun Jun 26 01:40:28 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 25 Jun 2011 23:40:28 +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: <1309045228.33.0.659157999882.issue11870@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> This skip gives very few information, and it is duplicated for each 
> function. I would prefer a constant of the "broken OSes" with your 
> following comment attached to the constant:

Ok, I'll try to write something along those lines.

> If the creation of a thread after a fork is reliable on some systems,
> we should not deny the creation of new threads after a fork.

Well, the problem is that it is not reliable on any platform, but happens to work "most of the time" on some platforms ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11870>
_______________________________________

From report at bugs.python.org  Sun Jun 26 01:53:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 25 Jun 2011 23:53:31 +0000
Subject: [issue12413] make faulthandler dump traceback of child processes
In-Reply-To: <1309046011.52.0.650507172396.issue12413@psf.upfronthosting.co.za>
Message-ID: <1309046011.52.0.650507172396.issue12413@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

As noted in issue #11870, making faulthandler capable of dumping child processes' tracebacks could be a great aid in debugging tricky deadlocks involving for example multiprocessing and subprocess.
Since there's no portable way to find out child processes, a possible idea would be to make the handler send a signal to its process group if the current process is the process group leader.
Advantages:
- simple
- async-safe
Drawbacks:
- since all the processes receive the signal at the same time, their outputs will be interleaved (we could maybe add a random sleep before dumping the traceback?)
- children not part of the same process group (for example those who called setsid() or setpgrp()) won't be handled

I'm not sure how this would work out on Windows, but I don't event know if Windows has a notion of child processes or process groups...

----------
components: Library (Lib)
messages: 139132
nosy: haypo, neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: make faulthandler dump traceback of child processes
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12413>
_______________________________________

From report at bugs.python.org  Sun Jun 26 02:27:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 26 Jun 2011 00:27:11 +0000
Subject: [issue12413] make faulthandler dump traceback of child processes
In-Reply-To: <1309046011.52.0.650507172396.issue12413@psf.upfronthosting.co.za>
Message-ID: <1309048031.56.0.168905710577.issue12413@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh oh. I already thaugh to this feature, but its implementation is not trivial.

> As noted in issue #11870 ...

You mean that the tracebacks of children should be dumped on a timeout of the parent? Or do you also want them on a segfault of the parent? In my experience, the most common problem with the multiprocessing and subprocess modules is the hang.

The timeout is implemeted using a (C) thread in faulthandler. You can do more in a thread than in a signal handler ;-) A hook may be added to faulthandler to execute code specific to multiprocessing / subprocess.

> send a signal to its process group if the current process
> is the process group leader

In which case is Python the leader of the group? Is it the case by default? Can we do something to ensure that in regrtest, in multiprocessing tests or the multiprocessing module?

See also #5115 (for the subprocess module).

The subprocess maintains a list of the create subprocesses: subprocess.alive, but you need a reference a reference to this list (or you can access it using the Python namespace, but it requires the GIL and you cannot trust the GIL on a crash). 

subprocess can execute any program, not only Python. Send an arbitrary signal to a child process can cause issues.

Does multiprocessing maintain a list of child processes?

--

By the way, which signal do you want to send to the child processes? A test may replace the signal handler of your signal (most test use SIGALRM and SIGUSR1).

faulthandler.register() is not available on Windows.

--

crier ( https://gist.github.com/737056 ) is a tool similar to faulthandler, but it is implemented in Python and so is less reliable. It uses a different trigger: it checks if a file (e.g. /tmp/crier-<pid>) does exists.

A file (e.g. a pipe) can be used with a thread watching the file to send the "please dump your traceback" request to the child processes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12413>
_______________________________________

From report at bugs.python.org  Sun Jun 26 02:36:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 26 Jun 2011 00:36:21 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <BANLkTimXSSB7fEg2gS5FgDamSh71ZS+SbA@mail.gmail.com>
Message-ID: <1309048593.28727.8.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> _pending_free uses a lock internally to make it thread-safe, so I
> think this will have exactly the same problem

You are probably right. Can't we use a lock-less list? list.append is
atomic thanks to the GIL, isn't it? But I don't know how to implement
the lock-less list consumer. It would be nice to have a function to
remove and return the content of the list, an atomic "content=mylist[:];
del mylist[:]" function.

> (the trylock can fail in case of contention or free() from multiple
> threads, thus we can't be
> sure that the else clause is executed on behalf of the garbage
> collector and it won't run while we're adding the block to
> _pending_free)

If two threads call free at same time, the "second" (taking the GIL)
will add the block to pending_free.

> Anyway, this seems complicated and error-prone, disabling the gc seems
> the most straightforward way to handle that.

I don't like touching such global "variable", but you are right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Sun Jun 26 02:42:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 26 Jun 2011 00:42:55 +0000
Subject: [issue12413] make faulthandler dump traceback of child processes
In-Reply-To: <1309046011.52.0.650507172396.issue12413@psf.upfronthosting.co.za>
Message-ID: <1309048975.99.0.281047921612.issue12413@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> since all the processes receive the signal at the same time,
> their outputs will be interleaved (we could maybe add a random
> sleep before dumping the traceback?)

And we have the pid list of the children, we can use an arbitrary sleep (e.g. 1 second) before sending a signal to the next pid. Anyway, a sleep is the most reliable synchronization code after a crash/timeout.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12413>
_______________________________________

From report at bugs.python.org  Sun Jun 26 02:43:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 26 Jun 2011 00:43:09 +0000
Subject: [issue12413] make faulthandler dump traceback of child processes
In-Reply-To: <1309046011.52.0.650507172396.issue12413@psf.upfronthosting.co.za>
Message-ID: <1309048989.74.0.0657016735534.issue12413@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
Removed message: http://bugs.python.org/msg139135

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12413>
_______________________________________

From report at bugs.python.org  Sun Jun 26 02:43:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 26 Jun 2011 00:43:39 +0000
Subject: [issue12413] make faulthandler dump traceback of child processes
In-Reply-To: <1309046011.52.0.650507172396.issue12413@psf.upfronthosting.co.za>
Message-ID: <1309049019.92.0.313744228563.issue12413@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> since all the processes receive the signal at the same time,
> their outputs will be interleaved (we could maybe add a random
> sleep before dumping the traceback?)

If we have the pid list of the children, we can use an arbitrary sleep (e.g. 1 second) before sending a signal to the next pid. Anyway, a sleep is the most reliable synchronization code after a crash/timeout.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12413>
_______________________________________

From report at bugs.python.org  Sun Jun 26 03:41:22 2011
From: report at bugs.python.org (John Edmonds)
Date: Sun, 26 Jun 2011 01:41:22 +0000
Subject: [issue12169] Factor out common code for d2 commands register,
	upload and upload_docs
In-Reply-To: <1306255725.22.0.23750798807.issue12169@psf.upfronthosting.co.za>
Message-ID: <1309052482.64.0.305624875653.issue12169@psf.upfronthosting.co.za>


John Edmonds <PocketCookies2 at gmail.com> added the comment:

Thanks for reviewing the patch.  I don't believe I received an email for the review.  I think I have addressed your comment about the usage of str(body) by removing the call to str() and changing the tests to use byte literals.

As for the content-length changing in the tests, that is because encode_multipart uses '\r\n' to end lines while the previous code only ended lines in '\n'.

----------
Added file: http://bugs.python.org/file22478/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12169>
_______________________________________

From report at bugs.python.org  Sun Jun 26 04:15:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 26 Jun 2011 02:15:53 +0000
Subject: [issue12376] unittest.TextTestResult.__init__ breaks under complex
	__mro__
In-Reply-To: <1308591554.84.0.206840920137.issue12376@psf.upfronthosting.co.za>
Message-ID: <1309054553.08.0.833246767659.issue12376@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think we'll have to wait for Micheal to double check, but it looks to me like there is a bug in unittest.TextTestResult.  TestResult's init expects the three arguments the OP is talking about, but defaults them to None.  TextTestResult accepts those three arguments in its init with no defaults, but does not pass them to the base class in the super call.  If this is intentional, I would say that it needs to be documented, since it is not obvious why it would be done that way, since it does, in fact, break the "cooperating classes" model required to use super correctly.

(As an aside, I was quite surprised to find TextTestResult in the runner.py file rather than the result.py file within the unittest package.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12376>
_______________________________________

From report at bugs.python.org  Sun Jun 26 04:25:48 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 26 Jun 2011 02:25:48 +0000
Subject: [issue12376] unittest.TextTestResult.__init__ does not pass on its
	init arguments in super call
In-Reply-To: <1308591554.84.0.206840920137.issue12376@psf.upfronthosting.co.za>
Message-ID: <1309055148.71.0.514974860878.issue12376@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: unittest.TextTestResult.__init__ breaks under complex __mro__ -> unittest.TextTestResult.__init__ does not pass on its init arguments in super call
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12376>
_______________________________________

From report at bugs.python.org  Sun Jun 26 05:14:15 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Jun 2011 03:14: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: <1309058055.92.0.299954615753.issue11682@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Sun Jun 26 05:19:51 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 26 Jun 2011 03:19:51 +0000
Subject: [issue10510] packaging upload/register should use CRLF in HTTP
	requests
In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za>
Message-ID: <1309058391.37.0.968829334125.issue10510@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I know this is closed so the comment may not be relevant, but the byte/string issues with email should be sorted out in the code that is in 3.2/3.3 at this point.  That is, it is possible once again to work with binary data, using the correct (new) classes.  If you have issues where things still don't work, please report them.  Note also that email now allows control of the generated linesep characters.  (That, unfortunately, won't help the python2 backport.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Sun Jun 26 05:42:31 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 26 Jun 2011 03:42:31 +0000
Subject: [issue11233] clarifying Availability: Unix
In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>
Message-ID: <1309059751.05.0.3390162036.issue11233@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In another issue Georg came up with the idea of creating an availability directive that would auto link to the appropriate text.  This would then apply to all our different availability types.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11233>
_______________________________________

From report at bugs.python.org  Sun Jun 26 05:48:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Jun 2011 03:48:44 +0000
Subject: [issue10020] docs for sqlite3 describe functions not available
	without recompiling
In-Reply-To: <1286124753.24.0.309036392806.issue10020@psf.upfronthosting.co.za>
Message-ID: <E1QagKw-0004wq-LJ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 804a60029091 by Senthil Kumaran in branch '2.7':
Fix Issue10020 - Doc update to sqlite3 module in 2.7 branch.
http://hg.python.org/cpython/rev/804a60029091

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10020>
_______________________________________

From report at bugs.python.org  Sun Jun 26 05:53:21 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 26 Jun 2011 03:53:21 +0000
Subject: [issue12414] getsizeof() on code objects is wrong
In-Reply-To: <1309060401.87.0.459388249467.issue12414@psf.upfronthosting.co.za>
Message-ID: <1309060401.87.0.459388249467.issue12414@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

sys.getsizeof() on a code object returns on the size of the code struct, not the arrays and tuples which it references.

----------
components: Interpreter Core
messages: 139142
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: getsizeof() on code objects is wrong
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12414>
_______________________________________

From report at bugs.python.org  Sun Jun 26 05:54:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Jun 2011 03:54:53 +0000
Subject: [issue12399] simplify cell var initialization by storing constant
	data on the code object
In-Reply-To: <1308931560.13.0.00225198817974.issue12399@psf.upfronthosting.co.za>
Message-ID: <E1QagQt-0005DE-Os@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c5b0585624ef by Benjamin Peterson in branch 'default':
map cells to arg slots at code creation time (closes #12399)
http://hg.python.org/cpython/rev/c5b0585624ef

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12399>
_______________________________________

From report at bugs.python.org  Sun Jun 26 06:03:26 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 26 Jun 2011 04:03:26 +0000
Subject: [issue10020] docs for sqlite3 describe functions not available
	without recompiling
In-Reply-To: <1286124753.24.0.309036392806.issue10020@psf.upfronthosting.co.za>
Message-ID: <1309061006.61.0.979555062341.issue10020@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Fixed in branch 2.7. Thanks Kristan. Eric, the documentation patch does not apply to 3.1 because those functions are not present in 3.1.

----------
nosy: +orsenthil
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10020>
_______________________________________

From report at bugs.python.org  Sun Jun 26 06:22:52 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Jun 2011 04:22:52 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1309062172.92.0.0416218553938.issue11682@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

OK, this isn't going to be as simple as I thought it was. The big problem is that the test suite from [1] needs to be refactored into a format that is suitable for use in regrtest. That means porting them to either unittest or doctest, as "golden output" tests of the style that Greg used are no longer accepted as part of the regression test suite.

[1] http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/yield_from.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Sun Jun 26 07:46:26 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jun 2011 05:46:26 +0000
Subject: [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1309067186.51.0.314980763707.issue12409@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I agree with Fred.

----------
nosy: +rhettinger
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12409>
_______________________________________

From report at bugs.python.org  Sun Jun 26 08:29:38 2011
From: report at bugs.python.org (Philip Olson)
Date: Sun, 26 Jun 2011 06:29:38 +0000
Subject: [issue12415] Missing: How to checkout the Doc sources
In-Reply-To: <1309069778.19.0.06342861361.issue12415@psf.upfronthosting.co.za>
Message-ID: <1309069778.19.0.06342861361.issue12415@psf.upfronthosting.co.za>


New submission from Philip Olson <philip at roshambo.org>:

I was unable to determine how to download the Python documentation source files (for building via Sphinx) but did figure out the following:

   hg clone http://hg.python.org/cpython
   cd cpython/Doc
   make html

Where to get the Doc sources deserves a mention here:

   http://docs.python.org/dev/documenting/building.html

I don't know this topic so won't propose a patch, but building.txt should mention where/how to get 'Doc' before the 'cd Doc' example.

----------
assignee: docs at python
components: Documentation
messages: 139147
nosy: docs at python, philip
priority: normal
severity: normal
status: open
title: Missing: How to checkout the Doc sources

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12415>
_______________________________________

From report at bugs.python.org  Sun Jun 26 09:07:57 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 26 Jun 2011 07:07:57 +0000
Subject: [issue12415] Missing: How to checkout the Doc sources
In-Reply-To: <1309069778.19.0.06342861361.issue12415@psf.upfronthosting.co.za>
Message-ID: <1309072077.38.0.766363779025.issue12415@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/issue12415>
_______________________________________

From report at bugs.python.org  Sun Jun 26 09:49:27 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 26 Jun 2011 07:49:27 +0000
Subject: [issue12211] Better document math.copysign behavior.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1309074567.02.0.116391635937.issue12211@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Taken from http://www.slac.stanford.edu/comp/unix/package/rtems/doc/html/libm/libm.info.copysign.html i'd suggest to extend

  Return a float with the magnitude of x

to

  Return a float with the magnitude (absolute value) of x

It could probably help people less math-savvy in understand what's going to happen :)

Maybe also (only in rest doc) might be nice to describe what happens in case the arguments are NaN, f.e.:

>>> import math
>>> x = float('nan')
>>> math.copysign(1., x)
1.0
>>> math.copysign(-1., x)
1.0
>>> math.copysign(x, -1)
nan
>>> math.copysign(x, x)
nan

umedoblock: would you like to expand the patch with these notes (unless someone objects :)).

----------
nosy: +sandro.tosi
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12211>
_______________________________________

From report at bugs.python.org  Sun Jun 26 09:51:44 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 26 Jun 2011 07:51:44 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1309074704.3.0.631623841575.issue12277@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Marking the issue as pending (inferred from ?ric msg): ?ric, will this be in your July big-push? :)

----------
nosy: +sandro.tosi
resolution:  -> accepted
stage:  -> commit review
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12277>
_______________________________________

From report at bugs.python.org  Sun Jun 26 10:06:29 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 26 Jun 2011 08:06:29 +0000
Subject: [issue12160] codecs doc: what is StreamCodec?
In-Reply-To: <1306166137.72.0.066960808058.issue12160@psf.upfronthosting.co.za>
Message-ID: <1309075589.25.0.309824099863.issue12160@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Victor, would you update the patch?

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12160>
_______________________________________

From report at bugs.python.org  Sun Jun 26 10:23:14 2011
From: report at bugs.python.org (engelbert gruber)
Date: Sun, 26 Jun 2011 08:23:14 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1309076594.76.0.957833642405.issue12291@psf.upfronthosting.co.za>


engelbert gruber <grubert at users.sourceforge.net> added the comment:

add interleaved writing to the same file (which might happen or not?)

the tests pass when vinay's marshal.c is applied.

sorry for another patch

----------
Added file: http://bugs.python.org/file22479/multiple_dump_load_read_write_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From goodwin.gt at gmail.com  Sun Jun 26 01:32:27 2011
From: goodwin.gt at gmail.com (goodwin.gt)
Date: Sat, 25 Jun 2011 16:32:27 -0700 (PDT)
Subject: [issue9720] zipfile writes incorrect local file header for
	large files in zip64
In-Reply-To: <1283835468.24.0.874482196307.issue9720@psf.upfronthosting.co.za>
References: <1283216540.17.0.624049939978.issue9720@psf.upfronthosting.co.za>
	<1283835468.24.0.874482196307.issue9720@psf.upfronthosting.co.za>
Message-ID: <31928738.post@talk.nabble.com>




> Alan McIntyre <alan.mcintyre at gmail.com> added the comment:
> 
> Here's an updated patch for the py3k trunk with tests.  This pretty much
> doubles the runtime of test_zipfile64.py.  The patch also removes some
> unnecessary code from the existing test_zipfile64 tests.
> 

Hello Alan

I've faced this problem too.
I start packing a 4.73GB file, and receive the "struct error" as follows:

1) Python 2.7.2 production:

...
  File "C:\Python27\lib\zipfile.py", line 1100, in write
    zinfo.file_size))
struct.error: integer out of range for 'L' format code

2) Python 3.2 production:

...
  File "C:\Python32\lib\zipfile.py", line 1142, in write
    zinfo.file_size))
struct.error: argument out of range



Environment: Windows 7 Ultimate 32bit

Everytime packing process fails at 4,981,808,577 byte

I need a patch for Python 2.7.2 .
Could you adapt your patch appropriately?

Thanks.

-- 
View this message in context: http://old.nabble.com/-issue9720--zipfile-writes-incorrect-local-file-header-for-large-files-in-zip64-tp29578646p31928738.html
Sent from the Python - python-bugs-list mailing list archive at Nabble.com.


From report at bugs.python.org  Sun Jun 26 10:38:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Jun 2011 08:38:39 +0000
Subject: [issue11669] Clarify Lang Ref "Compound statements" footnote
In-Reply-To: <1301042574.67.0.975748752077.issue11669@psf.upfronthosting.co.za>
Message-ID: <E1QakrW-0004ys-0A@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b11e7bc76d07 by Ezio Melotti in branch '2.7':
#11669: rephrase footnote in the Compound Statements page.
http://hg.python.org/cpython/rev/b11e7bc76d07

New changeset 74e9f94d8440 by Ezio Melotti in branch '3.2':
#11669: rephrase footnote in the Compound Statements page.
http://hg.python.org/cpython/rev/74e9f94d8440

New changeset a7099a3b5e5f by Ezio Melotti in branch 'default':
#11669: merge with 3.2.
http://hg.python.org/cpython/rev/a7099a3b5e5f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11669>
_______________________________________

From report at bugs.python.org  Sun Jun 26 10:41:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 26 Jun 2011 08:41:24 +0000
Subject: [issue11669] Clarify Lang Ref "Compound statements" footnote
In-Reply-To: <1301042574.67.0.975748752077.issue11669@psf.upfronthosting.co.za>
Message-ID: <1309077684.05.0.632114031676.issue11669@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: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11669>
_______________________________________

From report at bugs.python.org  Sun Jun 26 10:52:03 2011
From: report at bugs.python.org (umedoblock)
Date: Sun, 26 Jun 2011 08:52:03 +0000
Subject: [issue12211] Better document math.copysign behavior.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1309078323.06.0.0797735945469.issue12211@psf.upfronthosting.co.za>


umedoblock <umedoblock at gmail.com> added the comment:

sandro: OK, I attached the new patch.

----------
Added file: http://bugs.python.org/file22480/issue_12211_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12211>
_______________________________________

From report at bugs.python.org  Sun Jun 26 11:07:26 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jun 2011 09:07:26 +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: <1309079246.27.0.254522299669.issue11802@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

After more thought, will just close this report.  If a new project emerges to improve the design of filecmp, it can be done in a separate tracker entry.

----------
resolution: later -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Sun Jun 26 11:42:32 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 26 Jun 2011 09:42:32 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1309048593.28727.8.camel@marge>
Message-ID: <BANLkTi=nrP=1LUMNm6_ig4sH+Aszrr848w@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

[...]
> I don't like touching such global "variable", but you are right.
>

Well, I don't like it either, but I can't really think of any other solution.
Antoine, any thought on that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Sun Jun 26 11:46:48 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Sun, 26 Jun 2011 09:46:48 +0000
Subject: [issue9955] multiprocessing.Pipe segmentation fault when recv of
	unpicklable object
In-Reply-To: <1285527695.71.0.573625122377.issue9955@psf.upfronthosting.co.za>
Message-ID: <1309081608.78.0.0746976329469.issue9955@psf.upfronthosting.co.za>


Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com> added the comment:

On Python 2.7.2 this can not be reproduced. Instead of the segmentation fault an AssertionError is raised:

AssertionError: invalid Element proxy at 39359432

In Python 3.2 the p1.send(n) step in the example raises a PicklingError when trying to pass an unpickable object.

Recommend closing this ticket.

----------
nosy: +Kristian.Vlaardingerbroek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9955>
_______________________________________

From report at bugs.python.org  Sun Jun 26 11:49:12 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 26 Jun 2011 09:49:12 +0000
Subject: [issue9955] multiprocessing.Pipe segmentation fault when recv of
	unpicklable object
In-Reply-To: <1285527695.71.0.573625122377.issue9955@psf.upfronthosting.co.za>
Message-ID: <1309081752.46.0.168789793343.issue9955@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9955>
_______________________________________

From report at bugs.python.org  Sun Jun 26 11:58:14 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 26 Jun 2011 09:58:14 +0000
Subject: [issue11363] Curses - add missing functions to doc
In-Reply-To: <1299005402.55.0.443028099437.issue11363@psf.upfronthosting.co.za>
Message-ID: <1309082294.72.0.828928009972.issue11363@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

As requested by Ezio, I'm attaching a "pre-patch" to bring curses doc a bit more adherent to current standards like by s/Returns/Return/ , ``True`` instead of true and so on. It applies ok on 3.3 and 3.2, on 2.7 a hunk is failing (but Ezio said it's fine this way :)).

After this patch is applies, the previous one (to add missing functs) can be applied.

----------
nosy: +ezio.melotti
versions:  -Python 3.1
Added file: http://bugs.python.org/file22481/curses_doc_update.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11363>
_______________________________________

From report at bugs.python.org  Sun Jun 26 12:13:05 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 26 Jun 2011 10:13:05 +0000
Subject: [issue11363] Curses - add missing functions to doc
In-Reply-To: <1299005402.55.0.443028099437.issue11363@psf.upfronthosting.co.za>
Message-ID: <1309083185.0.0.537595441589.issue11363@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Still following Ezio suggestion, I've reworked a bit the original patch, attaching its -v2 .

----------
Added file: http://bugs.python.org/file22482/curses_missing_functs-py3k-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11363>
_______________________________________

From report at bugs.python.org  Sun Jun 26 12:14:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 26 Jun 2011 10:14:01 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1309048593.28727.8.camel@marge>
Message-ID: <BANLkTi=2eazNTXLs3GayOO-ijXbm_D+N9A@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> You are probably right. Can't we use a lock-less list? list.append is
> atomic thanks to the GIL, isn't it? But I don't know how to implement
> the lock-less list consumer. It would be nice to have a function to
> remove and return the content of the list, an atomic "content=mylist[:];
> del mylist[:]" function.
>

While not just something like:
While True:
    try:
        block = list.pop()
    except IndexError:
        break
    _free(block)

Lock-less lists are not strictly atomic (only on cPython), but I doubt
that gc.disable() is available and works on every Python interpreter
anyway...
So the idea would be:
- in free(), perform a trylock
- if trylock fails, append the block to a list of pending blocks to free
- if trylock succeeds, free the pending blocks and proceed as usual
(do the same thing in malloc())

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Sun Jun 26 12:25:42 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 26 Jun 2011 10:25:42 +0000
Subject: [issue12413] make faulthandler dump traceback of child processes
In-Reply-To: <1309048031.56.0.168905710577.issue12413@psf.upfronthosting.co.za>
Message-ID: <BANLkTikOq5WAFwyMQuy2jq3X1NDPC12AFg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> You mean that the tracebacks of children should be dumped on a timeout of the parent? Or do you also want them on a segfault of the parent? In my experience, the most common problem with the multiprocessing and subprocess modules is the hang.
>

Well, a segfault is due to the current process (or sometimes to
external conditions like OOM, but that's not the point here), so it's
not really useful to dump tracebacks of child processes in that case.
I was more thinking about timeouts.

> The timeout is implemeted using a (C) thread in faulthandler. You can do more in a thread than in a signal handler ;-) A hook may be added to faulthandler to execute code specific to multiprocessing / subprocess.
>

Yes, but when the timeout expires, there's no guarantee about the
state of the interpreter (for example in issue #12352 it was the GC
that deadlocked), so I guess we can't do anything too fancy.

> In which case is Python the leader of the group? Is it the case by default? Can we do something to ensure that in regrtest, in multiprocessing tests or the multiprocessing module?
>

Yes, it's the case by default when you launch a process through a shell.

> The subprocess maintains a list of the create subprocesses: subprocess.alive, but you need a reference a reference to this list (or you can access it using the Python namespace, but it requires the GIL and you cannot trust the GIL on a crash).
> Does multiprocessing maintain a list of child processes?

Yes, we don't have any guarantee about the interpreter's state, and
furthermore this won't work for processes calling fork() directly.

> subprocess can execute any program, not only Python. Send an arbitrary signal to a child process can cause issues.
>

Well, faulthandler is disabled by default, no ?

> By the way, which signal do you want to send to the child processes? A test may replace the signal handler of your signal (most test use SIGALRM and SIGUSR1).
>

Hum, SIGTERM maybe? Don't you register some fatal signals by default?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12413>
_______________________________________

From report at bugs.python.org  Sun Jun 26 12:30:20 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 26 Jun 2011 10:30:20 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1309084220.89.0.0599907558798.issue10181@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

[Nick]
> Another idea we may want to revisit is the PyManagedBuffer concept,
> which would be a true PyObject that existed solely to simplify sharing
> of Py_buffer structs.

> If memoryview used such an object internally, then copying and slicing
> would be quite simple - just INCREF the managed buffer instance without
> letting the original source object know anything was going on.


I think this is the nicest solution since memoryview would then always 
have a proper base object. Do I understand correctly that PyManagedBuffer
should only handle 1-dimensional objects?


There is an additional point about slicing and sub-views:

I think slicing (esp. multidimensional slicing) would be greatly simplified
if we added a requirement for the *exporting* object to provide a sliced
view. (The same applies to sub-views, also see source comments below [1]).

For example, an exporting object could provide a sliced view by adding 
a getslicedbufferproc to PyBufferProcs:

int PyObject_GetSlicedBuffer(PyObject *obj, Py_buffer *view, int flags, PyObject *key);


By "sliced view" I mean that the exporting object changes buf, shape and 
strides. There are several advantages:
 
  o The invariant that all allocated memory in the buffer belongs
    to the exporting object remains intact.

  o The responsibility for creating correct multidimensional sliced views
    is shifted to the implementor of the exporting object.





[1] memoryobject.c: 
 
      /* XXX There should be an API to create a subbuffer */
      /* XXX:  This needs to be fixed so it actually returns a sub-view */

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Jun 26 12:39:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Jun 2011 10:39:58 +0000
Subject: [issue11363] Curses - add missing functions to doc
In-Reply-To: <1299005402.55.0.443028099437.issue11363@psf.upfronthosting.co.za>
Message-ID: <E1Qamku-0003NE-Cg@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3eb9c31a0b03 by Ezio Melotti in branch '2.7':
#11363: clean up curses doc.
http://hg.python.org/cpython/rev/3eb9c31a0b03

New changeset 3dc602b1f4a2 by Ezio Melotti in branch '2.7':
#11363: add missing functions from curses doc. Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/3dc602b1f4a2

New changeset bb27baa1124a by Ezio Melotti in branch '3.2':
#11363: clean up curses doc.
http://hg.python.org/cpython/rev/bb27baa1124a

New changeset f852e2d556af by Ezio Melotti in branch '3.2':
#11363: add missing functions from curses doc. Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/f852e2d556af

New changeset b879bad40154 by Ezio Melotti in branch 'default':
#11363: merge with 3.2.
http://hg.python.org/cpython/rev/b879bad40154

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11363>
_______________________________________

From report at bugs.python.org  Sun Jun 26 12:41:51 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 26 Jun 2011 10:41:51 +0000
Subject: [issue11363] Curses - add missing functions to doc
In-Reply-To: <1299005402.55.0.443028099437.issue11363@psf.upfronthosting.co.za>
Message-ID: <1309084911.96.0.526066102287.issue11363@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/issue11363>
_______________________________________

From report at bugs.python.org  Sun Jun 26 12:44:54 2011
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 26 Jun 2011 10:44:54 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1309085094.95.0.0196098011604.issue11682@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/issue11682>
_______________________________________

From report at bugs.python.org  Sun Jun 26 12:44:59 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Sun, 26 Jun 2011 10:44:59 +0000
Subject: [issue11253] autodocument first appearance of ctypes.wintypes
	constants
In-Reply-To: <1298182426.14.0.687578094658.issue11253@psf.upfronthosting.co.za>
Message-ID: <1309085099.01.0.47716243119.issue11253@psf.upfronthosting.co.za>


Mark Mc Mahon <mtnbikingmark at gmail.com> added the comment:

This mostly a documentation concern - correct? ctypes.wintypes is sparsely documented - in 2.7 the help for it seems to be:
"The ctypes.wintypes module provides quite some other Windows specific data types, for example HWND, WPARAM, or DWORD. Some useful structures like MSG or RECT are also defined."

How about the following solution:
First of all get the previous release information
 - hg log / hg revert / import wintypes / dir(wintypes)

Future changes have to be updated manually (which probably is not a big deal as it is a reasonably stable module)

In fact I went and got the revision when each attribute was added... (some of those are just ctypes leakage)
{36899: ['ARRAY',                   'MSG',
         'ArgumentError',           'OLESTR',
         'Array',                   'OleDLL',
         'BOOL',                    'POINT',
         'BYTE',                    'POINTER',
         'BigEndianStructure',      'POINTL',
         'DEFAULT_MODE',            'PYFUNCTYPE',
         'DWORD',                   'PyDLL',
         'FILETIME',                'RECT',
         'FormatError',             'RECTL',
         'GetLastError',            'RGB',
         'HANDLE',                  'RTLD_GLOBAL',
         'HDC',                     'RTLD_LOCAL',
         'HGDIOBJ',                 'SIZE',
         'HINSTANCE',               'SIZEL',
         'HKEY',                    'SetPointerType',
         'HMENU',                   'Structure',
         'HMODULE',                 'ULARGE_INTEGER',
         'HPEN',                    'ULONG',
         'HRESULT',                 'Union',
         'HRGN',                    'VARIANT_BOOL',
         'HTASK',                   'WIN32_FIND_DATAA',
         'HWND',                    'WIN32_FIND_DATAW',
         'LARGE_INTEGER',           'WINFUNCTYPE',
         'LCID',                    'WORD',
         'LONG',                    'WPARAM',
         'LPARAM',                  'WinDLL',
         'LPCOLESTR',               'WinError',
         'LPCSTR',                  'alignment',
         'LPCWSTR',                 'get_errno',
         'LPOLESTR',                'get_last_error',
         'LPSTR',                   'resize',
         'LPWSTR',                  'set_conversion_mode',
         'LibraryLoader',           'set_errno',
         'LittleEndianStructure',   'set_last_error',
         'MAX_PATH',]

 38788: ['ATOM',                     'HRSRC',
         'BOOLEAN',                  'HSTR',
         'COLORREF',                 'HWINSTA',
         'HACCEL',                   'LANGID',
         'HBITMAP',                  'LCTYPE',
         'HBRUSH',                   'LGRPID',
         'HCOLORSPACE',              'SC_HANDLE',
         'HDESK',                    'SERVICE_STATUS_HANDLE',
         'HDWP',                     'SMALL_RECT',
         'HENHMETAFILE',             '_COORD',
         'HFONT',                    '_FILETIME',
         'HGLOBAL',                  '_POINTL',
         'HHOOK',                    '_RECTL',
         'HICON',                    '_SMALL_RECT',
         'HKL',                      'tagMSG',
         'HLOCAL',                   'tagPOINT',
         'HMETAFILE',                'tagRECT',
         'HMONITOR',                 'tagSIZE',
         'HPALETTE',]

 38830: ['DOUBLE',
         'UINT',
         'WCHAR',
         '_LARGE_INTEGER',
         '_SimpleCData',
         '_ULARGE_INTEGER',
         '__all__'],

 48320: ['FLOAT',
         'INT',
         'LPCVOID',
         'LPVOID',
         'SHORT',
         'USHORT']}

48320 -> 2.7?
38830 -> 2.5?
38788 -> 2.5?
36899 -> 2.4?

So we need a doc patch? Should we update the older 'What's new in Python 2.x' for added attribs?

----------
nosy: +markm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11253>
_______________________________________

From report at bugs.python.org  Sun Jun 26 12:47:57 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 26 Jun 2011 10:47:57 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1309085277.1.0.915737174713.issue12326@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> So people who say sys.platform shouldn't be used: what do you propose
> to do with Lib/plat-linux2 (or, more generally, Lib/plat-*)?

I can't speak, as I've never used those.
But can't those directories be renamed to Lib/plat-<platform.system()>?

As for the performance overhead, since the platform module caches the result of uname or other function/subprocess calls, I don't think it's a showstopper. Furthermore, I somehow doubt those functions are performance bottlenecks anyway.

Since Linux 3 is in RC now, is there a chance to reach a consensus in the near future?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sun Jun 26 13:44:41 2011
From: report at bugs.python.org (Jonas Meurer)
Date: Sun, 26 Jun 2011 11:44:41 +0000
Subject: [issue7744] Allow site.addsitedir insert to beginning of sys.path
In-Reply-To: <1264018763.75.0.862537731081.issue7744@psf.upfronthosting.co.za>
Message-ID: <1309088681.58.0.792277261358.issue7744@psf.upfronthosting.co.za>


Jonas Meurer <jonas at freesources.org> added the comment:

I would be interested in that feature as well. It's currently impossible to use custom new versions of a python module by adding the directory with site.addsitedir in case a old version of the module is already installed in the python systemwide path.

----------
nosy: +mejo
status: pending -> open
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7744>
_______________________________________

From report at bugs.python.org  Sun Jun 26 13:51:11 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 26 Jun 2011 11:51:11 +0000
Subject: [issue11493] Add python.exe-gdb.py to .hgignore
In-Reply-To: <1300088302.91.0.551103844028.issue11493@psf.upfronthosting.co.za>
Message-ID: <1309089071.45.0.317045512716.issue11493@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

@?ric: it was introduced with issue8032 to easy debugging python with gdb
@Santoso: this was fixed in the 2.7 branch with 421c941c529f -> closing.

----------
nosy: +sandro.tosi
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11493>
_______________________________________

From report at bugs.python.org  Sun Jun 26 14:23:48 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Jun 2011 12:23:48 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1308950511.74.0.296984998866.issue11457@psf.upfronthosting.co.za>
Message-ID: <4E0724D2.3080506@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> any broken-down time has issues of time stamp ordering in the
>> duplicate hour of switching from DST to normal time
> 
> I understand that it is an issue of the datetime module. Can it be
> solved, or is there a design issue in the module?

It's an inherent flaw of broken-down time. Don't use that
representation; the only true representation of point-in-time
is "seconds since the epoch, as a real number" (IMO, of course).
Broken-down time has the advantage of being more easily human-readable,
but is (often deliberately) incomplete (with the notion of partial
time stamps) and text representations are difficult to parse.

> I don't have a strong opinion on this issue, I just wanted to know
> why datetime cannot be used for this issue.

It's a personal preference of me (the strong objection to broken-down
time representations). I believe this preference is widely shared,
though. Notice how advanced file systems (NTFS, ext2) use seconds-since-
the-epoch formats, whereas FAT uses broken-down time. Also notice how
the daytime protocol uses broken-down time, and NTP uses
seconds-since-the epoch. The major variation point in the latter is
whether second fractions are represented as a separate number of not;
this is also the issue here. NTP and NTFS use a single number; ext2
uses seconds/nanoseconds. Also notice that NTP does *not* have a unit
that is an integral power of ten, but units of 2**-32s (ca. 233ps).
NTP4 supports a resolution of 2**-64s. (To be fair, the way NTP
represents time stamps can also be interpreted as a pair of
second/subsecond integers).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Sun Jun 26 14:30:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Jun 2011 12:30:42 +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: <E1QaoU4-0002Mz-Bd@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c0a68b948f5d by Raymond Hettinger in branch '3.2':
Issue #4608: urllib.request.urlopen does not return an iterable object
http://hg.python.org/cpython/rev/c0a68b948f5d

New changeset d4aeeddf72e3 by Raymond Hettinger in branch 'default':
Issue #4608: urllib.request.urlopen does not return an iterable object
http://hg.python.org/cpython/rev/d4aeeddf72e3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4608>
_______________________________________

From report at bugs.python.org  Sun Jun 26 14:31:12 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jun 2011 12:31:12 +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: <1309091472.29.0.298204780566.issue4608@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the patch.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4608>
_______________________________________

From report at bugs.python.org  Sun Jun 26 14:31:35 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Jun 2011 12:31:35 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1309091495.13.0.530537344735.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The idea of PyManagedBuffer is for it to be an almost completely passive object that *just* acts as a refcounted wrapper around the Py_buffer structure, so it doesn't care about the actual contents. The only supplemental functionality I think it should provide is to disallow explicitly releasing the buffer while the reference count is greater than 1. I'm OK with my example cited above being unreliable. The correct way to write such code would then be:

  with memoryview(obj) as m:
    with m[:] as m2:
      ...

I think separating the concerns this way, letting PyManagedBuffer worry about the lifecycle issues of the underlying buffer reference, while PyMemoryView deals with the *interpretation* of the buffer description (such as by providing useful slicing functionality) will make the whole arrangement easier to handle. When a memoryview is sliced, it would create a new memoryview that has a reference to the same PyManagedBuffer object, but different internal state that affects how that buffer is accessed. This is better than requiring that every implementor of the buffer API worry about the slicing logic - we can do it right in memoryview and then implementers of producer objects don't have to worry about it.

Currently, however, memoryview gets tied up in knots since it is trying to do everything itself in a way that makes it unclear what is going on. The semantics of copying the Py_buffer struct or of accessing the PEP 3118 API on the underlying object when slicing or copying views are demonstrably broken. If we try to shoehorn reference counting semantics into the current object model, we would end up with two distinct modes of operation for memoryview:

  Direct: the view is directly accessing an underlying object via the PEP 3118 API
  Indirect: the view has a reference to another memoryview object that it is using as a data source

That's complicated - hard to implement in the first place and hard to follow when reading the code. Adding the PyManagedBuffer object makes the object model more complex, but simplifies the runtime semantics: every memoryview instance will access a PyManagedBuffer object which takes care of the underlying PEP 3118 details. Direct use of the PEP 3118 consumer API in 3rd party code will also be strongly discouraged, with PyManagedBuffer promoted as the preferred alternative (producers, of course, will still need to provide the raw Py_buffer data that PyManagedBuffer exposes).

At the Python level, I don't think it is necessary to expose a new object, so we can stick with Antoine's preferred model where memoryview is the only public API. My proposed new PyManagedBuffer object would just be about making life easier at the C level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Jun 26 14:35:47 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Jun 2011 12:35:47 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1309091747.53.0.929388930196.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I should also note that if memoryview ends up growing enough state to cope correctly with numpy-style multi-dimensional slicing, I'm actually OK with that. You could get a long way just using the array module to allocate a large chunk of memory and then a suitably enhanced memoryview to manipulate it as a multidimensional array.

That's a future concern, though - for now, the key task is to migrate to reliable, reference based semantics for Py_buffer management.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Jun 26 14:44:27 2011
From: report at bugs.python.org (Dave King)
Date: Sun, 26 Jun 2011 12:44:27 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1309092267.12.0.79365824984.issue8890@psf.upfronthosting.co.za>


Dave King <dave at davbo.org> added the comment:

Spotted another use of /tmp/ in the logging howto. Attached a diff.

----------
nosy: +davbo
Added file: http://bugs.python.org/file22483/tmp_logging_howto.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Sun Jun 26 15:00:35 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 26 Jun 2011 13:00:35 +0000
Subject: [issue11689] sqlite: Incorrect unit test fails to detect failure
In-Reply-To: <1301178520.82.0.473046584416.issue11689@psf.upfronthosting.co.za>
Message-ID: <1309093235.98.0.496583481402.issue11689@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I've commented on the Rietveld review page - forgive me if I missed something and didn't get the patch meaning right.

----------
nosy: +sandro.tosi
stage:  -> patch review
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11689>
_______________________________________

From report at bugs.python.org  Sun Jun 26 15:29:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Jun 2011 13:29:44 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <E1QapPC-0005pD-Ri@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1ed71544fceb by Raymond Hettinger in branch '3.2':
Issue #8890: Remove /tmp from examples.
http://hg.python.org/cpython/rev/1ed71544fceb

New changeset fcf242243d46 by Raymond Hettinger in branch 'default':
Issue #8890: Remove /tmp from examples.
http://hg.python.org/cpython/rev/fcf242243d46

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Sun Jun 26 15:30:07 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jun 2011 13:30:07 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1309095007.57.0.477948304376.issue8890@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Sun Jun 26 15:30:27 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 26 Jun 2011 13:30:27 +0000
Subject: [issue11895] pybench prep_times calculation error
In-Reply-To: <1303356013.22.0.66518331753.issue11895@psf.upfronthosting.co.za>
Message-ID: <1309095027.31.0.509374206791.issue11895@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
nosy: +sandro.tosi
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11895>
_______________________________________

From report at bugs.python.org  Sun Jun 26 15:54:36 2011
From: report at bugs.python.org (Stefan Schwarzer)
Date: Sun, 26 Jun 2011 13:54:36 +0000
Subject: [issue1067702] urllib fails with multiple ftp transfers
Message-ID: <1309096476.65.0.601910763947.issue1067702@psf.upfronthosting.co.za>


Stefan Schwarzer <sschwarzer at sschwarzer.net> added the comment:

I was able to get some error output with the code of the OP. However, I only saw the "opposite" message, such as:

Retrieval of 'ftp://ftp.gnome.org/pub/debian/dists/stable/main/source/Sources.bz2' failed with error: [Errno ftp error] 200 Switching to Binary mode.

I had to change the used FTP server and path because I had problems connecting to that server.

Even with the guidelines by the OP, I could trigger the bug only occasionally.

I converted the script to be executable with manual intervention (see attachment). Still, sometimes both files are also successfully downloaded in the second iteration (i. e. the "outer" iteration which downloads both files).

These results are from a test with Python 2.6.6. I plan to continue testing with the tip of the Python 2.7 branch.

----------
nosy: +sschwarzer
title: urllib fails with multiple ftps -> urllib fails with multiple ftp transfers
Added file: http://bugs.python.org/file22484/urllibftpbug-non-interactive.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1067702>
_______________________________________

From report at bugs.python.org  Sun Jun 26 16:13:36 2011
From: report at bugs.python.org (Stefan Schwarzer)
Date: Sun, 26 Jun 2011 14:13:36 +0000
Subject: [issue1067702] urllib fails with multiple ftp transfers
Message-ID: <1309097616.69.0.112200905579.issue1067702@psf.upfronthosting.co.za>


Stefan Schwarzer <sschwarzer at sschwarzer.net> added the comment:

> I converted the script to be executable with manual intervention (see attachment).

This should have been "without manual intervention". :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1067702>
_______________________________________

From report at bugs.python.org  Sun Jun 26 16:17:17 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jun 2011 14:17:17 +0000
Subject: [issue12384] difflib.SequenceMatcher and Match: code and doc bugs
In-Reply-To: <1308686441.84.0.396418173173.issue12384@psf.upfronthosting.co.za>
Message-ID: <1309097837.05.0.373291746381.issue12384@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Go head an patch the first self.matching_blocks to also return a named tuple.  Also, correct any doctests or examples using these.

The docs could also mention that list of namedtuples with fields a, b, and size is returned by get_matching_blocks().

----------
assignee: rhettinger -> terry.reedy
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12384>
_______________________________________

From report at bugs.python.org  Sun Jun 26 16:29:11 2011
From: report at bugs.python.org (Stefan Schwarzer)
Date: Sun, 26 Jun 2011 14:29:11 +0000
Subject: [issue1067702] urllib fails with multiple ftp transfers
Message-ID: <1309098551.82.0.676464950559.issue1067702@psf.upfronthosting.co.za>


Stefan Schwarzer <sschwarzer at sschwarzer.net> added the comment:

I can confirm the bug for the Python 2.7 tip (changeset b11e7bc76d07) after using the script urllibftpbug-non-interactive.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1067702>
_______________________________________

From report at bugs.python.org  Sun Jun 26 16:30:38 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 26 Jun 2011 14:30:38 +0000
Subject: [issue12211] Better document math.copysign behavior.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1309098638.12.0.874891731282.issue12211@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

well, what I actually meant is to describe the behavior in case one (or both) of the arguments is NaN (so not cut&pasting the code), while the example was just provided as a quick reference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12211>
_______________________________________

From report at bugs.python.org  Sun Jun 26 16:41:51 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jun 2011 14:41:51 +0000
Subject: [issue12134] json.dump much slower than dumps
In-Reply-To: <1305985086.83.0.259963774289.issue12134@psf.upfronthosting.co.za>
Message-ID: <1309099311.34.0.582273765684.issue12134@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

As Antoine and Eric stated, the module is working as intended and we don't document implementation details and generally stay away from talking about performance in the docs.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12134>
_______________________________________

From report at bugs.python.org  Sun Jun 26 16:51:18 2011
From: report at bugs.python.org (engelbert gruber)
Date: Sun, 26 Jun 2011 14:51:18 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1309099878.82.0.400343404079.issue8890@psf.upfronthosting.co.za>


engelbert gruber <grubert at users.sourceforge.net> added the comment:

Assumption:

  /tmp is used in examples so the examples work 
  because /tmp is always writeable

module tempfile is for creating temporary files, the name of which is unimported, when a user is trying code from documentation it might be hard on him/her to additionally guess/save the random filenames.

``grep tmp -r CPython3.3/Doc`` (trimmed results and grouped)

* Doc/distutils/install.rst, Doc/install/install.rst:

  e.g. ``--install-base=/tmp`` 

  maybe ``--install-base=<other-python-base-directory>``
  if someone installs to another directory, one has a reason and 
  therefore knows the directory.

* all other e.g. ::

    Doc/library/sqlite3.rst::file:`/tmp/example` file::
    Doc/library/sqlite3.rst:   conn = sqlite3.connect('/tmp/example')

  use ``/tmp`` because it is writeable, but assuming the user wants
  to program i think it is not so big a burden to assume him/her to
  grasp the concept of directories, files and write protection.

  So either it can be left out, as in sqlite3.rst, maybe a file 
  extension would be more helpful, or replaced by a placeholder
  like ``<my-log-directory>`` or ``<directory-for-tempfiles>``.

  I am unsure about the ``<>`` chars ?

list of files:

Doc/distutils/install.rst
Doc/documenting/fromlatex.rst
Doc/howto/logging-cookbook.rst
Doc/install/install.rst
Doc/library/atexit.rst
Doc/library/cgi.rst
Doc/library/imghdr.rst
Doc/library/mailcap.rst
Doc/library/nntplib.rst
Doc/library/optparse.rst
Doc/library/packaging.database.rst
Doc/library/packaging.pypi.simple.rst
Doc/library/pipes.rst
Doc/library/sqlite3.rst
Doc/library/tempfile.rst
Doc/library/trace.rst
Doc/library/zipimport.rst
Doc/tools/sphinxext/susp-ignored.csv
Doc/tutorial/inputoutput.rst

So which way ?

----------
nosy: +grubert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Sun Jun 26 16:52:11 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 26 Jun 2011 14:52:11 +0000
Subject: [issue11469] Fix resource warning in test_trailers
In-Reply-To: <1299869493.16.0.824147350306.issue11469@psf.upfronthosting.co.za>
Message-ID: <1309099931.62.0.426135316227.issue11469@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

This has been fixed by Brett in 9050675cb94e .

----------
nosy: +sandro.tosi
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11469>
_______________________________________

From report at bugs.python.org  Sun Jun 26 16:53:54 2011
From: report at bugs.python.org (Stefan Schwarzer)
Date: Sun, 26 Jun 2011 14:53:54 +0000
Subject: [issue1067702] urllib fails with multiple ftp transfers
Message-ID: <1309100034.37.0.364773986355.issue1067702@psf.upfronthosting.co.za>


Stefan Schwarzer <sschwarzer at sschwarzer.net> added the comment:

After running the adapted test script three times for Python 3 tip (changeset c5b0585624ef), I didn't get an error message / exception.

----------
Added file: http://bugs.python.org/file22485/urllibftpbug-non-interactive-py3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1067702>
_______________________________________

From report at bugs.python.org  Sun Jun 26 17:10:56 2011
From: report at bugs.python.org (Stefan Schwarzer)
Date: Sun, 26 Jun 2011 15:10:56 +0000
Subject: [issue1067702] urllib fails with multiple ftp transfers
Message-ID: <1309101056.44.0.520948729337.issue1067702@psf.upfronthosting.co.za>


Stefan Schwarzer <sschwarzer at sschwarzer.net> added the comment:

The traceback and its context for the exception raised in Python 2.7 is:

...
################################################################################################### 99 %
################################################################################################### 99 %
#################################################################################################### 100 %
Done retrieving 'ftp://ftp.gnome.org/pub/debian/dists/stable/main/source/Sources.bz2'; read 4539023 bytes
Start retrieving 'ftp://ftp.gnome.org/pub/debian/dists/stable/main/source/Sources.bz2'
Start retrieving 'ftp://ftp.gnome.org/pub/debian/dists/stable/main/source/Sources.bz2'
Retrieval of 'ftp://ftp.gnome.org/pub/debian/dists/stable/main/source/Sources.bz2' failed with error: [Errno ftp error] 200 Switching to Binary mode.
Traceback (most recent call last):
  File "urllibftpbug-non-interactive.py", line 62, in _getTask
    self._fromFile = urllib.urlopen(self.fromURL)
  File "/home/schwa/sd/python/cpython/Lib/urllib.py", line 84, in urlopen
    return opener.open(url)
  File "/home/schwa/sd/python/cpython/Lib/urllib.py", line 205, in open
    return getattr(self, name)(url)
  File "/home/schwa/sd/python/cpython/Lib/urllib.py", line 548, in open_ftp
    (fp, retrlen) = self.ftpcache[key].retrfile(file, type)
  File "/home/schwa/sd/python/cpython/Lib/urllib.py", line 886, in retrfile
    conn = self.ftp.ntransfercmd(cmd)
  File "/home/schwa/sd/python/cpython/Lib/ftplib.py", line 326, in ntransfercmd
    host, port = self.makepasv()
  File "/home/schwa/sd/python/cpython/Lib/ftplib.py", line 304, in makepasv
    host, port = parse227(self.sendcmd('PASV'))
  File "/home/schwa/sd/python/cpython/Lib/ftplib.py", line 790, in parse227
    raise error_reply, resp
IOError: [Errno ftp error] 200 Switching to Binary mode.
Total bytes: 4539023
 0 %
 0 %
 0 %
...

I printed the traceback by adding traceback.print_exc() at the end of the _getTask method:

        except Exception, e:
            self._cleanup(e)
            traceback.print_exc()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1067702>
_______________________________________

From report at bugs.python.org  Sun Jun 26 17:11:51 2011
From: report at bugs.python.org (engelbert gruber)
Date: Sun, 26 Jun 2011 15:11:51 +0000
Subject: [issue5950] Make zipimport work with zipfile containing comments
In-Reply-To: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za>
Message-ID: <1309101111.94.0.945531396581.issue5950@psf.upfronthosting.co.za>


engelbert gruber <grubert at users.sourceforge.net> added the comment:

+1*4

----------
nosy: +grubert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5950>
_______________________________________

From report at bugs.python.org  Sun Jun 26 17:12:30 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 26 Jun 2011 15:12:30 +0000
Subject: [issue11568] docstring of select.epoll.register() is wrong
In-Reply-To: <1300271962.07.0.948411199474.issue11568@psf.upfronthosting.co.za>
Message-ID: <1309101150.64.0.082995361798.issue11568@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

The patch is fine: but would you be interested in trying to write a unittest for select.epoll.register ? it would be really nice to start having 'select' tested (oh no, don't ask me how to test select since I have no idea :)).

----------
nosy: +sandro.tosi
stage:  -> patch review
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11568>
_______________________________________

From report at bugs.python.org  Sun Jun 26 17:16:40 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 26 Jun 2011 15:16:40 +0000
Subject: [issue11302] Add more tests to test_ast.py
In-Reply-To: <1298496457.65.0.147228634144.issue11302@psf.upfronthosting.co.za>
Message-ID: <1309101400.36.0.32962955895.issue11302@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Benjamin, we know have rietveld directly integrated in the tracker, so it might be time to add you comments? If you still can remember them, given it passed some time :)

----------
nosy: +sandro.tosi
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11302>
_______________________________________

From report at bugs.python.org  Sun Jun 26 17:25:18 2011
From: report at bugs.python.org (mouad)
Date: Sun, 26 Jun 2011 15:25:18 +0000
Subject: [issue12038] assertEqual doesn't display newline differences quite
	well
In-Reply-To: <1304959012.21.0.957539258305.issue12038@psf.upfronthosting.co.za>
Message-ID: <1309101918.12.0.299581700079.issue12038@psf.upfronthosting.co.za>


mouad <mouadino at gmail.com> added the comment:

I took on consideration the two suggestion that was in the issue and create this patch that basically show only until the last character that differ and truncate the rest.

I just included one test case, other test case if they should be included (and if my solution got accepted :)), should be more *complex* and check using Regex the correctness of the assertion message, but here is the output that we can see when applying the patch:

>>> tc.assertEqual("x\n" * 40 + "\n", "x\n" * 40 + "\r\n")

'x\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\n...nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\n\n [truncated]... != 'x\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\n...\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\n\r [truncated]...
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
- 
+ 


>>> tc.assertEqual('aaaa', 'abbb')

AssertionError: 'aa [truncated]... != 'ab [truncated]...
- aaaa
+ abbb

>>> tc.assertEqual('aaaa', 'bbbb')

AssertionError: 'a [truncated]... != 'b [truncated]...
- aaaa
+ bbbb

>>> tc.assertEqual("x\n" * 80 + "\n", "x\n" * 80 + "\r")

AssertionError: 'x\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\n...nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\n\n [truncated]... != 'x\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\n...nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\n\r [truncated]...

----------
keywords: +patch
nosy: +mouad
Added file: http://bugs.python.org/file22486/issue-12038.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12038>
_______________________________________

From report at bugs.python.org  Sun Jun 26 18:54:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 16:54:18 +0000
Subject: [issue12211] Better document math.copysign behavior.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1309107258.76.0.141486345153.issue12211@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with adding '(absolute value)'. I think the following covers the NaN behavior. "NaN acts as a positive value that cannot be negated." This should be added to both doc and docstring.

I do not think we generally specify the nan behavior for each function, but it usually follows general rules. The copysign(x,nan) behavior is not obvious as nan, like int 0, does not really have a sign. One might expect copysign(-1.0,nan) to be -1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12211>
_______________________________________

From report at bugs.python.org  Sun Jun 26 19:19:39 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 17:19:39 +0000
Subject: [issue5950] Make zipimport work with zipfile containing comments
In-Reply-To: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za>
Message-ID: <1309108779.82.0.232768628748.issue5950@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Brett, Nick, this could be considered a patch to the import machinery as the bugs shows with a import statement. In any case, no one is signed up for zipimport specifically.

----------
nosy: +brett.cannon, ncoghlan
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5950>
_______________________________________

From report at bugs.python.org  Sun Jun 26 19:58:05 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 26 Jun 2011 17:58:05 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1309111085.41.0.489580837452.issue10181@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Jun 26 20:01:05 2011
From: report at bugs.python.org (flashk)
Date: Sun, 26 Jun 2011 18:01:05 +0000
Subject: [issue10583] Encoding issue with chm help in 2.7.1
In-Reply-To: <1291060108.22.0.631034667944.issue10583@psf.upfronthosting.co.za>
Message-ID: <1309111265.0.0.441360347435.issue10583@psf.upfronthosting.co.za>


flashk <flashk at gmail.com> added the comment:

Yes, I still notice this issue with the 2.7.2 release.

As I mentioned earlier, I did not notice this problem with 2.7. Were there any significant changes to the docs between 2.7 and 2.7.1?

Considering the bug with HTML Help pointed out by Kristian, I'm thinking there was either a change in the html encoding or the build environment for the Windows installer. Anybody aware of either of these changes happening between 2.7 and 2.7.1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10583>
_______________________________________

From report at bugs.python.org  Sun Jun 26 20:20:44 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 26 Jun 2011 18:20:44 +0000
Subject: [issue12255] A few changes to .*ignore
In-Reply-To: <1309034284.2.0.0707523549856.issue12255@psf.upfronthosting.co.za>
Message-ID: <20110626182038.GA2710@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

On Sat, Jun 25, 2011 at 08:38:04PM +0000, Senthil Kumaran wrote:
>  As I am not affected by remains of .rej and .orig (neither have I
>  found their usefulness (yet)), so my concerns can be stepped over. 

Just a side-note. I wondered why is my case so, and I realized that I
had integrated k3diff to handle any conflicts during merge so when a
conflict arises, it immediately invokes k3diff and it allowed me to
handle the conflicts giving me the contexts which are stored in .rej
files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12255>
_______________________________________

From report at bugs.python.org  Sun Jun 26 20:48:17 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 26 Jun 2011 18:48:17 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>
Message-ID: <1309114097.94.0.635249171155.issue12303@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

>From the FreeBSD 6.4 buildbot:
"""
[172/356/2] test_signal
error: 'NoneType' object has no attribute 'si_signo'
error: False is not true
test test_signal failed -- multiple errors occurred; run in verbose mode for details
Re-running test test_signal in verbose mode
test_getsignal (test.test_signal.PosixTests) ... ok
test_out_of_range_signal_number_raises_error (test.test_signal.PosixTests) ... ok
test_setting_signal_handler_to_none_raises_error (test.test_signal.PosixTests) ... ok
test_main (test.test_signal.InterProcessSignalTests) ... skipped 'inter process signals not reliable (do not mix well with threading) on freebsd6'
test_pending (test.test_signal.WakeupSignalTests) ... ok
test_pthread_kill_main_thread (test.test_signal.WakeupSignalTests) ... ok
test_signum (test.test_signal.WakeupSignalTests) ... ok
test_wakeup_fd_during (test.test_signal.WakeupSignalTests) ... ok
test_wakeup_fd_early (test.test_signal.WakeupSignalTests) ... ok
test_siginterrupt_off (test.test_signal.SiginterruptTest) ... ok
test_siginterrupt_on (test.test_signal.SiginterruptTest) ... ok
test_without_siginterrupt (test.test_signal.SiginterruptTest) ... ok
test_itimer_exc (test.test_signal.ItimerTest) ... ok
test_itimer_prof (test.test_signal.ItimerTest) ... skipped 'itimer not reliable (does not mix well with threading) on freebsd6'
test_itimer_real (test.test_signal.ItimerTest) ... ok
test_itimer_virtual (test.test_signal.ItimerTest) ... skipped 'itimer not reliable (does not mix well with threading) on some BSDs.'
test_issue9324 (test.test_signal.WindowsSignalTests) ... skipped 'Windows specific'
test_pthread_kill (test.test_signal.PendingSignalsTests) ... ok
test_pthread_sigmask (test.test_signal.PendingSignalsTests) ... ok
test_pthread_sigmask_arguments (test.test_signal.PendingSignalsTests) ... ok
test_sigpending (test.test_signal.PendingSignalsTests) ... ok
test_sigpending_empty (test.test_signal.PendingSignalsTests) ... ok
test_sigtimedwait (test.test_signal.PendingSignalsTests) ... ok
test_sigtimedwait_negative_timeout (test.test_signal.PendingSignalsTests) ... ok
test_sigtimedwait_poll (test.test_signal.PendingSignalsTests) ... error: 'NoneType' object has no attribute 'si_signo'
FAIL
test_sigtimedwait_timeout (test.test_signal.PendingSignalsTests) ... ok
test_sigwait (test.test_signal.PendingSignalsTests) ... ok
test_sigwait_thread (test.test_signal.PendingSignalsTests) ... ok
test_sigwaitinfo (test.test_signal.PendingSignalsTests) ... ok
test_sigwaitinfo_interrupted (test.test_signal.PendingSignalsTests) ... error: False is not true
FAIL

======================================================================
FAIL: test_sigtimedwait_poll (test.test_signal.PendingSignalsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_signal.py", line 685, in test_sigtimedwait_poll
    self.wait_helper(test, self.handler, signal.SIGALRM)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_signal.py", line 645, in wait_helper
    self.assertEqual(os.waitpid(pid, 0), (pid, 0))
AssertionError: Tuples differ: (55455, 256) != (55455, 0)

First differing element 1:
256
0

- (55455, 256)
?         ^^^

+ (55455, 0)
?         ^


======================================================================
FAIL: test_sigwaitinfo_interrupted (test.test_signal.PendingSignalsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_signal.py", line 721, in test_sigwaitinfo_interrupted
    self.wait_helper(test, self.alarm_handler, signal.SIGUSR1)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_signal.py", line 645, in wait_helper
    self.assertEqual(os.waitpid(pid, 0), (pid, 0))
AssertionError: Tuples differ: (55460, 256) != (55460, 0)

First differing element 1:
256
0

- (55460, 256)
?         ^^^

+ (55460, 0)
?         ^
"""




@Victor, you've had some experience with fixing signals on the FreeBSD 6 buildbot.
Have you got any ideas as to what the cause of this may be?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Sun Jun 26 20:49:46 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 18:49:46 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1309114186.06.0.778439115077.issue6721@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sun Jun 26 20:50:48 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 18:50:48 +0000
Subject: [issue6717] Some problem with recursion handling
In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>
Message-ID: <1309114248.04.0.786687161167.issue6717@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6717>
_______________________________________

From report at bugs.python.org  Sun Jun 26 20:51:34 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 18:51:34 +0000
Subject: [issue8743] set() operators don't work with collections.Set instances
In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>
Message-ID: <1309114294.95.0.594178185637.issue8743@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8743>
_______________________________________

From report at bugs.python.org  Sun Jun 26 20:57:00 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 18:57:00 +0000
Subject: [issue1669349] make install fails if no previous Python installation
Message-ID: <1309114620.69.0.26343782079.issue1669349@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am closing this because none of the reports are for current versions (2.7,3.2)

----------
nosy: +terry.reedy
resolution:  -> out of date
status: open -> closed
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1669349>
_______________________________________

From report at bugs.python.org  Sun Jun 26 20:58:37 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 18:58:37 +0000
Subject: [issue1475523] gettext breaks on plural-forms header
Message-ID: <1309114717.42.0.6765547439.issue1475523@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1475523>
_______________________________________

From report at bugs.python.org  Sun Jun 26 20:59:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 18:59:24 +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: <1309114764.54.0.0848670242659.issue11726@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11726>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:01:06 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 19:01:06 +0000
Subject: [issue4924] gc.collect() won't always collect as expected
In-Reply-To: <1231765413.97.0.063026202194.issue4924@psf.upfronthosting.co.za>
Message-ID: <1309114866.48.0.238998125111.issue4924@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2, Python 3.3 -Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4924>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:01:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 19:01:19 +0000
Subject: [issue4924] gc.collect() won't always collect as expected
In-Reply-To: <1231765413.97.0.063026202194.issue4924@psf.upfronthosting.co.za>
Message-ID: <1309114879.06.0.746591260997.issue4924@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4924>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:01:46 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 19:01:46 +0000
Subject: [issue4672] Distutils SWIG support blocks use of SWIG -outdir option
In-Reply-To: <1229379752.29.0.666537313596.issue4672@psf.upfronthosting.co.za>
Message-ID: <1309114906.76.0.398423132873.issue4672@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4672>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:03:16 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 19:03:16 +0000
Subject: [issue5159] Indicating packages to be loaded when a Tcl interpreter
	is created in tkinter
In-Reply-To: <1233864505.11.0.366828040714.issue5159@psf.upfronthosting.co.za>
Message-ID: <1309114997.0.0.356069614816.issue5159@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
type:  -> feature request
versions: +Python 3.3 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5159>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:03:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 19:03:47 +0000
Subject: [issue5225] OS X "Update Shell Profile" may not update $PATH if run
	more than once
In-Reply-To: <1234440346.58.0.444916712806.issue5225@psf.upfronthosting.co.za>
Message-ID: <1309115027.12.0.778189063125.issue5225@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2, Python 3.3 -Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5225>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:03:59 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 19:03:59 +0000
Subject: [issue5225] OS X "Update Shell Profile" may not update $PATH if run
	more than once
In-Reply-To: <1234440346.58.0.444916712806.issue5225@psf.upfronthosting.co.za>
Message-ID: <1309115039.66.0.863022299491.issue5225@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5225>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:09:30 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 19:09:30 +0000
Subject: [issue5375] Unified locals/consts array + register-based instructions
In-Reply-To: <1235657334.5.0.583024676615.issue5375@psf.upfronthosting.co.za>
Message-ID: <1309115370.11.0.0677259921014.issue5375@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This a type of feature request and such a change would only go into a new version. Given the absence of response from djc, perhaps this should be closed as languishing-postponed?

----------
nosy: +terry.reedy
versions: +Python 3.3 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5375>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:21:15 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 19:21:15 +0000
Subject: [issue978604] wait_variable hangs at exit
Message-ID: <1309116075.84.0.984947214156.issue978604@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In 3.2, winxp, (with Tkinter => tkinter), I get
invalid command name "12277720callit"
    while executing
"12277720callit"
    ("after" script)
and no new prompt and ^C ineffective. Had to kill command window.
With IDLE, get nothing and have to kill with Task Manager.
So confirmed for 3.x.

----------
nosy: +terry.reedy
versions: +Python 3.2, Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue978604>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:26:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 19:26:01 +0000
Subject: [issue5661] asyncore should catch EPIPE while sending() and
	receiving()
In-Reply-To: <1238634207.37.0.10074614667.issue5661@psf.upfronthosting.co.za>
Message-ID: <1309116361.2.0.77747358978.issue5661@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am not marking 'test needed' since the problem is 'hardly reproducible'.

----------
nosy: +stutzbach, terry.reedy -josiah.carlson
stage:  -> patch review
versions: +Python 3.2, Python 3.3 -Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5661>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:29:30 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 19:29:30 +0000
Subject: [issue5619] Pass MS CRT debug flags into subprocesses
In-Reply-To: <1238472783.0.0.132667741337.issue5619@psf.upfronthosting.co.za>
Message-ID: <1309116570.84.0.497540403698.issue5619@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5619>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:32:54 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 19:32:54 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <1309116774.2.0.600475010688.issue4591@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2, Python 3.3 -Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:33:04 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 19:33:04 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <1309116784.86.0.371955767811.issue4591@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:41:32 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Jun 2011 19:41:32 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1308995950.75.0.288905614048.issue12406@psf.upfronthosting.co.za>
Message-ID: <1309117292.01.0.319665205669.issue12406@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This looks fine, except for the Tk changes, which should not be made.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12406>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:46:26 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 19:46:26 +0000
Subject: [issue5722] settimer / gettimer functionality on FreeBSD 6.3 (not 7.x)
In-Reply-To: <1239187744.6.0.565034475162.issue5722@psf.upfronthosting.co.za>
Message-ID: <1309117586.42.0.501288655087.issue5722@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am following Andrew's suggestion. This issue can serve as 'don't do that' doc.

The 3.2 README has been edited and slimmed down by Georg Brandl. It is limited to general build instructions. It would not be the place for such a nit. It does say "You can pass many options to the configure script; run "./configure --help" to find out more." I do not know if that gives system specific hints.

It seems to me that the wiki might be a place for system-specific instructions, with a page like BuildingWithFreeBSD, etc.

----------
nosy: +terry.reedy
resolution:  -> wont fix
status: open -> closed
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5722>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:47:40 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 26 Jun 2011 19:47:40 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1308995950.75.0.288905614048.issue12406@psf.upfronthosting.co.za>
Message-ID: <1309117660.76.0.513434071135.issue12406@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Thanks, Martin. I've realised there are more additions due to packaging - for example there is a whole set of "wininst-X.Y[-amd64].exe" files in Lib/packaging/command. I won't commit anything just yet - I've made the changes I need to my local branch for testing.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12406>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:49:03 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 26 Jun 2011 19:49:03 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1309117743.44.0.122622049059.issue12291@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


Added file: http://bugs.python.org/file22487/0feab4e7b27f.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:49:53 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Jun 2011 19:49:53 +0000
Subject: [issue12382] [msilib] Obscure exception message when trying to open a
	non-existent MSI database
In-Reply-To: <1308658337.05.0.630810191443.issue12382@psf.upfronthosting.co.za>
Message-ID: <1309117793.38.0.991662363633.issue12382@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'd add them to msierror, with no inclusion of the file name.

If you want the file name in the exception, you should uniformly apply this to all errors in OpenDatabase, and then subclass MSIError to, say, MSIOpenError which includes a .filename attribute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12382>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:53:22 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 26 Jun 2011 19:53:22 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1309118002.5.0.714899235641.issue12291@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I've incorporated Engelbert's two patches into test_marshal.py in my sandbox fix branch. I coalesced them into a single additional test in the existing BugsTestCase.

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:54:49 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 19:54:49 +0000
Subject: [issue5700] io.FileIO calls flush() after file closed
In-Reply-To: <1238945758.46.0.01809197792.issue5700@psf.upfronthosting.co.za>
Message-ID: <1309118089.14.0.976599746015.issue5700@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The original snippet works the same on 3.2.0. Was their any conclusion as to whether or not a change should be made?

----------
nosy: +terry.reedy
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5700>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:55:10 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 19:55:10 +0000
Subject: [issue5875] test_distutils failing on OpenSUSE 10.3, Py3k
In-Reply-To: <1240991372.08.0.469372196929.issue5875@psf.upfronthosting.co.za>
Message-ID: <1309118110.83.0.0678479902886.issue5875@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5875>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:56:43 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 26 Jun 2011 19:56:43 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1308995950.75.0.288905614048.issue12406@psf.upfronthosting.co.za>
Message-ID: <1309118203.91.0.126924716649.issue12406@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

BTW I made those Tcl/Tk changes because the instructions point to getting the files from the svn repository (using svn export), and they unpack into directories with a hyphen before the "8".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12406>
_______________________________________

From report at bugs.python.org  Sun Jun 26 21:56:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 19:56:47 +0000
Subject: [issue1662] [patch] assert tp_traverse in PyType_GenericAlloc()
In-Reply-To: <1198084921.68.0.0736452990224.issue1662@psf.upfronthosting.co.za>
Message-ID: <1309118207.08.0.279241565592.issue1662@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1662>
_______________________________________

From report at bugs.python.org  Sun Jun 26 22:04:03 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Jun 2011 20:04:03 +0000
Subject: [issue12414] getsizeof() on code objects is wrong
In-Reply-To: <1309060401.87.0.459388249467.issue12414@psf.upfronthosting.co.za>
Message-ID: <1309118643.34.0.831030686435.issue12414@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

For composite objects, getsizeof should only return the memory of the object itself, and not that of other objects it refers to. "the object itself" definitely includes the struct of the object, and also definitely includes non-PyObject blocks uniquely referred to by the object. It definitely should not return objects it reports in gc.get_referents. It probably should include PyObjects not shared with any other object, and not accessible from outside of the object.

There are boundary cases, such as memory blocks which are not PyObject, but may be shared across objects, and PyObjects not reported in get_referents.

It seems this case is the latter: the PyObjects are not returned from get_referents, but are certainly available to Python, e.g. through co_code and co_consts.

I don't think there sizes should be added to the size of the PyObject, since otherwise accounting algorithms may account for it twice.

What's your use case for including it in the total size?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12414>
_______________________________________

From report at bugs.python.org  Sun Jun 26 22:08:35 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Jun 2011 20:08:35 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1309085277.1.0.915737174713.issue12326@psf.upfronthosting.co.za>
Message-ID: <4E0791C2.3090702@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I can't speak, as I've never used those. But can't those directories
> be renamed to Lib/plat-<platform.system()>?

That would be incorrect for some systems. For example, FreeBSD does
change sets of symbolic constants across system releases (mostly
additions, but sometimes also removals). Back then, SunOS 4 and SunOS
5 were completely unrelated systems.

> Since Linux 3 is in RC now, is there a chance to reach a consensus in
> the near future?

Doesn't look like it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sun Jun 26 22:09:22 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 20:09:22 +0000
Subject: [issue5895] socketmodule.c on HPUX ia64 without
	_XOPEN_SOURCE_EXTENDED compiles incorrectly
In-Reply-To: <1241195874.94.0.470854501498.issue5895@psf.upfronthosting.co.za>
Message-ID: <1309118962.6.0.85773573468.issue5895@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Naoyuki, unless you can confirm that Daniel's patch works, we will have to close this as out-of-date.

Martin: PEP 11 lists platforms no-longer supported, but does not list those that are. For writing/reviewing patches like this, it would be helpful if it did. Is __hpux __ia64 a supported platform, so that this would be a legal patch? With the OP apparently not interested, there seems to be no one to test such patches.

----------
nosy: +loewis, terry.reedy
versions: +Python 3.2, Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5895>
_______________________________________

From report at bugs.python.org  Sun Jun 26 22:11:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 26 Jun 2011 20:11:07 +0000
Subject: [issue12413] make faulthandler dump traceback of child processes
In-Reply-To: <BANLkTikOq5WAFwyMQuy2jq3X1NDPC12AFg@mail.gmail.com>
Message-ID: <1309119059.31782.12.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> > In which case is Python the leader of the group? ...
> 
> Yes, it's the case by default when you launch a process through a shell.

subprocess doesn't use a shell by default, and I don't think that
multiprocessing uses a shell to start Python.

> > The subprocess maintains a list of the create subprocesses: subprocess.alive, but you need a reference a reference to this list (or you can access it using the Python namespace, but it requires the GIL and you cannot trust the GIL on a crash).
> > Does multiprocessing maintain a list of child processes?
> 
> Yes, we don't have any guarantee about the interpreter's state, and
> furthermore this won't work for processes calling fork() directly.

I don't think that we can have a reliable, generic and portable solution
for this issue. I suggest to only focus on one use case (debug the
multiprocessing and/or subprocess module), and latter try to support
more cases.

I agree that interpreter state can be inconsistent, but faulthandler
does already use read the interpreter state. We cannot do better than
"best effort". Well, it doesn't really matter if faulthandler crashs,
the program is already dying ;-)

To simplify the implementation, I propose to patch multiprocessing
and/or subprocess to register the pid of the child process in a list in
the faulthandler module.

It would be better if these modules unregister pid when a subprocess
exits, but it's not mandatory. We can send a signal to a non existant
process. In the worst case, on a heavy loaded computer, another process
may get the same pid, but it's unlikely. I'm quite sure that
multiprocessing and subprocess already handle the subprocess exit, so it
should be quite simply to add a hook.

> > subprocess can execute any program, not only Python.
> > Send an arbitrary signal to a child process can cause issues.
> Well, faulthandler is disabled by default, no ?

Yes, but I prefer to interfer with unrelated processes if it's possible.

> > By the way, which signal do you want to send to the child processes?
> 
> Hum, SIGTERM maybe? Don't you register some fatal signals by default?

faulthandler.enable() installs a signal handler for SIGSEGV, SIGBUS,
SIGILL and SIGABRT signals. (SIGKILL cannot be handled by the
application.)

> > A test may replace the signal handler of your signal

Well, it's doesn't really matter. If one child process doesn't print the
traceback, you have less information, but it is unlikely and we may get
the information manually or by changing temporary the signal number.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12413>
_______________________________________

From report at bugs.python.org  Sun Jun 26 22:14:54 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Jun 2011 20:14:54 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1309118203.91.0.126924716649.issue12406@psf.upfronthosting.co.za>
Message-ID: <4E07933C.5030205@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> BTW I made those Tcl/Tk changes because the instructions point to
> getting the files from the svn repository (using svn export), and
> they unpack into directories with a hyphen before the "8".

Yes, that's unfortunate. These instructions are not correct (they
are not wrong, either); they don't support Tix, but Tix support
is required for the official releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12406>
_______________________________________

From report at bugs.python.org  Sun Jun 26 22:19:30 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Jun 2011 20:19:30 +0000
Subject: [issue5895] socketmodule.c on HPUX ia64
	without	_XOPEN_SOURCE_EXTENDED compiles incorrectly
In-Reply-To: <1309118962.6.0.85773573468.issue5895@psf.upfronthosting.co.za>
Message-ID: <4E079450.2040004@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Martin: PEP 11 lists platforms no-longer supported, but does not list
> those that are.

You mean, "doesn't list the platforms that are still supported"?

That's on purpose: the point of PEP 11 is to warn current users about
forthcoming changes, not to track support status for specific platforms.

> For writing/reviewing patches like this, it would be
> helpful if it did. Is __hpux __ia64 a supported platform, so that
> this would be a legal patch? With the OP apparently not interested,
> there seems to be no one to test such patches.

Python never worked really well on HP-UX, but it worked in some form
for a long time. Don't know whether that makes it a "supported
platform". Accepting patches for HP-UX is fine with me. It would be
better if some committer could confirm that the patch actually works,
and also confirm that it doesn't break other releases of HP-UX.

----------
title: socketmodule.c  on HPUX ia64 without _XOPEN_SOURCE_EXTENDED compiles incorrectly -> socketmodule.c on HPUX ia64 without	_XOPEN_SOURCE_EXTENDED compiles incorrectly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5895>
_______________________________________

From report at bugs.python.org  Sun Jun 26 22:27:48 2011
From: report at bugs.python.org (sbt)
Date: Sun, 26 Jun 2011 20:27:48 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>
Message-ID: <1309120068.89.0.241589833761.issue12328@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

sigint_event.patch is a patch to make
_multiprocessing.win32.WaitForMultipleObjects interruptible.  It
applies directly on to default.

The patch also adds functions _PyOS_SigintEvent and _PyOS_IsMainThread
which are implemented in signalmodule.c and declared in intrcheck.c.

_PyOS_SigintEvent returns a manual reset event (cast to void*) which
is set whenever SIGINT is received.  It is Windows only.

_PyOS_IsMainThread returns 0 or 1 according to whether the current
thread is the main thread.

The time and _multiprocessing modules have been updated to use these
functions.

Note that WaitForMultipleObjects has a bWaitAll parameter.  When this
is true, all handles in the array are waited for, and
WaitForMultipleObjects is not interruptible.

----------
Added file: http://bugs.python.org/file22488/sigint_event.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Sun Jun 26 22:29:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 26 Jun 2011 20:29:28 +0000
Subject: [issue12392] pthread_kill() doesn't work on the main thread on
	FreeBSD6
In-Reply-To: <1308869761.72.0.972861691614.issue12392@psf.upfronthosting.co.za>
Message-ID: <1309120168.41.0.230145572654.issue12392@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/issue12392>
_______________________________________

From report at bugs.python.org  Sun Jun 26 22:41:13 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 20:41:13 +0000
Subject: [issue3435] 3rd party program calls trace.py on non Python files
In-Reply-To: <1216895941.29.0.346900095215.issue3435@psf.upfronthosting.co.za>
Message-ID: <1309120873.79.0.684989313576.issue3435@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The patch adds this check:

+	    if not filename.endswith((".pyc", ".pyo", ".py")):
+                continue

This is not valid. A Python file is a text file with python code. In spite of import conventions, they are not required to have any particular extension and some people omit them from main scripts. Trace works fine with such files now and your patch would prevent that. Python files are only identified as such by trying to parse them.

The problem and solution lie with your setup. Arrange things so Bitten only treats Python files as Python files.

----------
nosy: +terry.reedy
resolution:  -> invalid
stage: test needed -> patch review
status: open -> closed
title: trace.py tries to get coverage data from non Python files -> 3rd party program calls trace.py on non Python files
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3435>
_______________________________________

From report at bugs.python.org  Sun Jun 26 22:43:36 2011
From: report at bugs.python.org (sbt)
Date: Sun, 26 Jun 2011 20:43:36 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>
Message-ID: <1309121016.23.0.180947173576.issue12328@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

I have noticed a few more problems.

* Because poll() isn't thread safe on Windows, neither is Queue.empty().  Since a queue's pipe will never contain empty messages, this can be fixed easily by using (a wrapper for) win32.PeekNamedPipe().

* PipeListener/PipeClient have not been updated to use overlapped I/O.

* If more than one process is to read from a pipe connection then (even with proper synchronisation) we cannot safely use poll() since it can leave a partial message in the pipe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Sun Jun 26 22:45:02 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 20:45:02 +0000
Subject: [issue3635] pickle.dumps cannot save instance of dict-derived class
	that overrides __getattribute__
In-Reply-To: <1219346500.78.0.74794831892.issue3635@psf.upfronthosting.co.za>
Message-ID: <1309121102.74.0.477197763731.issue3635@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Should this be closed for the same reason #1730480 was?
If not, would this effectively be a feature request and have to wait for a new version (3.3)?

----------
nosy: +alexandre.vassalotti, pitrou, terry.reedy
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3635>
_______________________________________

From report at bugs.python.org  Sun Jun 26 22:45:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Jun 2011 20:45:46 +0000
Subject: [issue1067702] urllib fails with multiple ftp transfers
Message-ID: <E1QawDA-0007th-MB@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a4d418e8010d by Senthil Kumaran in branch '2.7':
Fix closes issue1067702  The problem with close multiple ftp transfers were due cases where sockets/file were not closed immediately. Tightned those cases and failure is no longer observed.
http://hg.python.org/cpython/rev/a4d418e8010d

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1067702>
_______________________________________

From report at bugs.python.org  Sun Jun 26 22:46:43 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 20:46:43 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1309121203.77.0.360093113918.issue5308@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> needs patch
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5308>
_______________________________________

From report at bugs.python.org  Sun Jun 26 22:50:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 26 Jun 2011 20:50:09 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>
Message-ID: <1309121409.97.0.00261398089512.issue12303@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> @Victor, you've had some experience with fixing signals
> on the FreeBSD 6 buildbot...

It's not exactly that I had some experience, it's just that I have a SSH access to the buildbot.

The following code hangs for (exactly?) 30 seconds on sigwaitinfo():
----
import os, signal, threading
s = signal.SIGALRM
signal.pthread_sigmask(signal.SIG_BLOCK, [s])
os.kill(os.getpid(), s)
signal.sigwaitinfo([s])
signal.pthread_sigmask(signal.SIG_UNBLOCK, [s])
----
sigwait() and sigtimedwait() wait also 30 seconds.

The following code only hangs for 1 second using sigwait(), sigwaitinfo() or sigtimedwait():
----
import os, signal, threading
s = signal.SIGALRM
signal.pthread_sigmask(signal.SIG_BLOCK, [s])
os.kill(os.getpid(), s)
signal.sigwaitinfo([s])
signal.pthread_sigmask(signal.SIG_UNBLOCK, [s])
----

test_sigtimedwait_poll() should be skipped on FreeBSD 6, there is a bug in the OS.

test_sigwaitinfo_interrupted() fails because SIGALRM signal handler is called, and the default FreeBSD handler stops the process. You should install a dummy signal handler (e.g. lambda signum, frame: None) for SIGALRM. I don't understand why the test doesn't fail on Linux, the default handler of SIGALRM on Linux stops also the process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Sun Jun 26 22:55:08 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 26 Jun 2011 20:55:08 +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: <1309045228.33.0.659157999882.issue11870@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=xaR9PO2T=1o7E=_2gHvRJ5j=nLg@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

Patch attached.

----------
Added file: http://bugs.python.org/file22489/test_threading_fork.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11870>
_______________________________________
-------------- next part --------------
diff -r fca745bc70be Lib/test/test_threading.py
--- a/Lib/test/test_threading.py	Sat Jun 25 16:31:06 2011 +0200
+++ b/Lib/test/test_threading.py	Sun Jun 26 22:50:42 2011 +0200
@@ -418,6 +418,13 @@
 
 class ThreadJoinOnShutdown(BaseTestCase):
 
+    # Between fork() and exec(), only async-safe functions are allowed (issues
+    # #12316 and #11870), and fork() from a worker thread is known to trigger
+    # problems with some operating systems (issue #3863): skip problematic tests
+    # on platforms known to behave badly.
+    platforms_to_skip = ('freebsd4', 'freebsd5', 'freebsd6', 'netbsd5',
+                         'os2emx')
+
     def _run_and_join(self, script):
         script = """if 1:
             import sys, os, time, threading
@@ -448,6 +455,7 @@
         self._run_and_join(script)
 
     @unittest.skipUnless(hasattr(os, 'fork'), "needs os.fork()")
+    @unittest.skipIf(sys.platform in platforms_to_skip, "due to known OS bug")
     def test_2_join_in_forked_process(self):
         # Like the test above, but from a forked interpreter
         script = """if 1:
@@ -464,15 +472,11 @@
         self._run_and_join(script)
 
     @unittest.skipUnless(hasattr(os, 'fork'), "needs os.fork()")
+    @unittest.skipIf(sys.platform in platforms_to_skip, "due to known OS bug")
     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():
@@ -498,15 +502,11 @@
         self.assertEqual(data, expected_output)
 
     @unittest.skipUnless(hasattr(os, 'fork'), "needs os.fork()")
+    @unittest.skipIf(sys.platform in platforms_to_skip, "due to known OS bug")
     def test_4_joining_across_fork_in_worker_thread(self):
         # There used to be a possible deadlock when forking from a child
         # thread.  See http://bugs.python.org/issue6643.
 
-        # Skip platforms with known problems forking from a worker thread.
-        # See http://bugs.python.org/issue3863.
-        if sys.platform in ('freebsd4', 'freebsd5', 'freebsd6', 'os2emx'):
-            raise unittest.SkipTest('due to known OS bugs on ' + sys.platform)
-
         # The script takes the following steps:
         # - The main thread in the parent process starts a new thread and then
         #   tries to join it.
@@ -575,6 +575,7 @@
         self.assertScriptHasOutput(script, "end of main\n")
 
     @unittest.skipUnless(hasattr(os, 'fork'), "needs os.fork()")
+    @unittest.skipIf(sys.platform in platforms_to_skip, "due to known OS bug")
     def test_5_clear_waiter_locks_to_avoid_crash(self):
         # Check that a spawned thread that forks doesn't segfault on certain
         # platforms, namely OS X.  This used to happen if there was a waiter
@@ -587,10 +588,6 @@
         # lock will be acquired, we can't know if the internal mutex will be
         # acquired at the time of the fork.
 
-        # Skip platforms with known problems forking from a worker thread.
-        # See http://bugs.python.org/issue3863.
-        if sys.platform in ('freebsd4', 'freebsd5', 'freebsd6', 'os2emx'):
-            raise unittest.SkipTest('due to known OS bugs on ' + sys.platform)
         script = """if True:
             import os, time, threading
 

From report at bugs.python.org  Sun Jun 26 22:55:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 26 Jun 2011 20:55:31 +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: <1309121731.59.0.496558396081.issue11870@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22468/test_threading_fork.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11870>
_______________________________________

From report at bugs.python.org  Sun Jun 26 22:57:30 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 26 Jun 2011 20:57:30 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <BANLkTi=2eazNTXLs3GayOO-ijXbm_D+N9A@mail.gmail.com>
Message-ID: <BANLkTimR7g8ca3u0vg+4POHjKsUq_zEMHw@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

Here's a patch based on the second approach.

----------
Added file: http://bugs.python.org/file22490/heap_gc_deadlock_lockless.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________
-------------- next part --------------
diff -r fca745bc70be Lib/multiprocessing/heap.py
--- a/Lib/multiprocessing/heap.py	Sat Jun 25 16:31:06 2011 +0200
+++ b/Lib/multiprocessing/heap.py	Sun Jun 26 19:57:56 2011 +0200
@@ -101,6 +101,8 @@
         self._stop_to_block = {}
         self._allocated_blocks = set()
         self._arenas = []
+        # list of pending blocks to free - see free() comment below
+        self._pending_free_blocks = []
 
     @staticmethod
     def _roundup(n, alignment):
@@ -175,15 +177,39 @@
 
         return start, stop
 
+    def _free_pending_blocks(self):
+        # Free all the blocks in the pending list - called with the lock held.
+        while True:
+            try:
+                block = self._pending_free_blocks.pop()
+            except IndexError:
+                break
+            self._free(block)
+            self._allocated_blocks.remove(block)
+
     def free(self, block):
         # free a block returned by malloc()
+        # Since free() can be called asynchronously by the GC, it could happen
+        # that it's called while self._lock is held: in that case,
+        # self._lock.acquire() would deadlock (issue #12352). To avoid that, a
+        # trylock is used instead, and if the lock can't be acquired
+        # immediately, the block is added to a list of blocks to be freed
+        # synchronously sometimes later from malloc() or free(), by calling
+        # _free_pending_blocks() (appending and retrieving from a list is not
+        # strictly thread-safe but under cPython it's atomic thanks to the GIL).
         assert os.getpid() == self._lastpid
-        self._lock.acquire()
-        try:
-            self._allocated_blocks.remove(block)
-            self._free(block)
-        finally:
-            self._lock.release()
+        if not self._lock.acquire(0):
+            # can't acquire the lock, add it to the list of pending blocks to
+            # free
+            self._pending_free_blocks.append(block)
+        else:
+            # we hold the lock
+            try:
+                self._free_pending_blocks()
+                self._allocated_blocks.remove(block)
+                self._free(block)
+            finally:
+                self._lock.release()
 
     def malloc(self, size):
         # return a block of right size (possibly rounded up)
@@ -191,6 +217,7 @@
         if os.getpid() != self._lastpid:
             self.__init__()                     # reinitialize after fork
         self._lock.acquire()
+        self._free_pending_blocks()
         try:
             size = self._roundup(max(size,1), self._alignment)
             (arena, start, stop) = self._malloc(size)
diff -r fca745bc70be Lib/test/test_multiprocessing.py
--- a/Lib/test/test_multiprocessing.py	Sat Jun 25 16:31:06 2011 +0200
+++ b/Lib/test/test_multiprocessing.py	Sun Jun 26 19:57:56 2011 +0200
@@ -1737,7 +1737,31 @@
             (narena, nstart, nstop) = all[i+1][:3]
             self.assertTrue((arena != narena and nstart == 0) or
                             (stop == nstart))
-
+                            
+    def test_free_from_gc(self):
+        # Check that freeing of blocks by the garbage collector doesn't deadlock
+        # (issue #12352).
+        # Make sure the GC is enabled, and set lower collection thresholds to
+        # make collections more frequent (and increase the probability of
+        # deadlock).
+        if gc.isenabled():
+            thresholds = gc.get_threshold()
+            self.addCleanup(gc.set_threshold, *thresholds)
+        else:
+            gc.enable()
+            self.addCleanup(gc.disable)
+        gc.set_threshold(10)
+
+        # perform numerous block allocations, with cyclic references to make
+        # sure objects are collected asynchronously by the gc
+        for i in range(5000):
+            a = multiprocessing.heap.BufferWrapper(1)
+            b = multiprocessing.heap.BufferWrapper(1)
+            # circular references
+            a.buddy = b
+            b.buddy = a
+
+ 
 #
 #
 #

From report at bugs.python.org  Sun Jun 26 23:00:07 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 21:00:07 +0000
Subject: [issue6396] '' % object() raises TypeError
In-Reply-To: <1246464847.52.0.736883285817.issue6396@psf.upfronthosting.co.za>
Message-ID: <1309122007.94.0.846492539314.issue6396@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The original bug claim is invalid. But the following (3.2.0, winxp) strike me as a bug, hence the title change

>>> class A: pass

>>> '' % A()
''
>>> '' % object()
...
TypeError: not all arguments converted during string formatting

More difference:

>>> '%(a)s' % object()
...
TypeError: format requires a mapping
>>> '%(a)s' % A()
...
TypeError: 'A' object is not subscriptable

----------
nosy: +terry.reedy
title: No conversion specifier in the string, no __getitem__ method in the right hand value -> '' % object() raises TypeError
versions: +Python 3.2, Python 3.3 -Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6396>
_______________________________________

From report at bugs.python.org  Sun Jun 26 23:04:46 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 21:04:46 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1309122286.48.0.450479646042.issue5999@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Sridhar, is there still a problem with current 3.2/3?

If you are no longer working on this, I think we should close as languishing/postponed.

----------
nosy: +terry.reedy
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Sun Jun 26 23:07:46 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 26 Jun 2011 21:07:46 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1309122466.38.0.873567979783.issue11197@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

The module documentation for the SimpleHTTPServer class says that.

"""

   This class serves files from the current directory and below, directly
   mapping the directory structure to HTTP requests.

"""

As it is already documented. Nothing else needs to be done for this report. Closing this one. Thanks!

----------
resolution:  -> invalid
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11197>
_______________________________________

From report at bugs.python.org  Sun Jun 26 23:09:14 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 26 Jun 2011 21:09:14 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <4E0791C2.3090702@v.loewis.de>
Message-ID: <BANLkTimA4JZa6qWb1TUan=YLgK0s9TKxdQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> That would be incorrect for some systems. For example, FreeBSD does
> change sets of symbolic constants across system releases (mostly
> additions, but sometimes also removals). Back then, SunOS 4 and SunOS
> 5 were completely unrelated systems.
>

Well, I don't see the problem in that case.
If what's intended is to target different operating systems releases,
then sys.platform is the right choice and should be kept, since it
embeds the major version number.
The point I (and others) have been trying to make is that 99% of the
time, people using sys.platform really mean platform.system() or
uname[0], since they're only interested in the operating system, and
don't care about the release. That's true of the vast majority of such
occurrences in Lib/test, and probably true of the vast majority of the
user code base.
Furthermore, at least on Linux, the major version number doesn't mean
anything, since features are added and removed in "minor" versions,
and Linux 3.0 doesn't have anything special as far as features as
concerned (as explained by Linus, a version number is just a number).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sun Jun 26 23:14:39 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 21:14:39 +0000
Subject: [issue6531] atexit_callfuncs() crashing within Py_Finalize() when
	using multiple interpreters.
In-Reply-To: <1248175169.79.0.15962102552.issue6531@psf.upfronthosting.co.za>
Message-ID: <1309122879.58.0.927428919545.issue6531@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

What did you mean by 'crash'? An exception or a segfault or equivalent?

I believe the finalization code was reworked a bit last fall, so could you determine whether or not there is still a problem in 3.2.1? Do not bother with 3.1.4 unless you think this is a security problem.

----------
nosy: +terry.reedy
versions:  -Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6531>
_______________________________________

From report at bugs.python.org  Sun Jun 26 23:16:56 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 21:16:56 +0000
Subject: [issue4765] IDLE fails to "Delete Custom Key Set" properly
In-Reply-To: <1230525520.13.0.417394561266.issue4765@psf.upfronthosting.co.za>
Message-ID: <1309123016.04.0.808493718065.issue4765@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2, Python 3.3 -Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4765>
_______________________________________

From report at bugs.python.org  Sun Jun 26 23:18:31 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 26 Jun 2011 21:18:31 +0000
Subject: [issue11253] autodocument first appearance of ctypes.wintypes
	constants
In-Reply-To: <1309085099.01.0.47716243119.issue11253@psf.upfronthosting.co.za>
Message-ID: <20110626211827.GC2710@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

On Sun, Jun 26, 2011 at 10:44:59AM +0000, Mark Mc Mahon wrote:
> So we need a doc patch? Should we update the older 'What's new in
> Python 2.x' for added attribs?

The Documentation patch may be applied only 2.7 and 3.2/3.3 releases
now. What's new is updated for the upcoming release only.

So, if documenting those constants will help in 2.7.x and 3.2.x and
3.3, it would be helpful to provide patches against those lines and it
can be applied. As you said, the future version can be updated, but we
cannot go back with updating the documentation of the already released
versions.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11253>
_______________________________________

From senthil at uthcode.com  Sun Jun 26 23:18:27 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sun, 26 Jun 2011 14:18:27 -0700
Subject: [issue11253] autodocument first appearance of ctypes.wintypes
	constants
In-Reply-To: <1309085099.01.0.47716243119.issue11253@psf.upfronthosting.co.za>
References: <1298182426.14.0.687578094658.issue11253@psf.upfronthosting.co.za>
	<1309085099.01.0.47716243119.issue11253@psf.upfronthosting.co.za>
Message-ID: <20110626211827.GC2710@mathmagic>

On Sun, Jun 26, 2011 at 10:44:59AM +0000, Mark Mc Mahon wrote:
> So we need a doc patch? Should we update the older 'What's new in
> Python 2.x' for added attribs?

The Documentation patch may be applied only 2.7 and 3.2/3.3 releases
now. What's new is updated for the upcoming release only.

So, if documenting those constants will help in 2.7.x and 3.2.x and
3.3, it would be helpful to provide patches against those lines and it
can be applied. As you said, the future version can be updated, but we
cannot go back with updating the documentation of the already released
versions.


From report at bugs.python.org  Sun Jun 26 23:33:00 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jun 2011 21:33:00 +0000
Subject: [issue6673] Uncaught comprehension SyntaxError eats up all memory
In-Reply-To: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>
Message-ID: <1309123980.41.0.401311923182.issue6673@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

With 32bit winxp Windows Task Manager open to Processes, sorted by Men Usage, I verified expanding memory usage in 3.2.0 (and stopped at 200 mb versus normal <20Mb). While we do not expect compiler to catch while True: pass, it would be nice if this was, with a reasonable error message.

No one marked for 2.7 because behavior only occurs with genexp and Nick says not so clearly a SyntaxError.

----------
nosy: +terry.reedy
title: Py3.1 hangs in coroutine and eats up all memory -> Uncaught comprehension SyntaxError eats up all memory
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6673>
_______________________________________

From report at bugs.python.org  Sun Jun 26 23:55:17 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 26 Jun 2011 21:55:17 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1308995305.23.0.132392157923.issue12405@psf.upfronthosting.co.za>
Message-ID: <1309125317.31.0.209305576951.issue12405@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I see that there's code to do this in install.py, but for some reason it seems not to be working in Windows. Investigating.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Mon Jun 27 00:15:18 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 26 Jun 2011 22:15:18 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1308995305.23.0.132392157923.issue12405@psf.upfronthosting.co.za>
Message-ID: <1309126518.67.0.713239134072.issue12405@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

More info on the problem (not Windows specific): if the installation creates a file several levels down

a/b/c/file

then during removal, only a/b/c is regarded as a candidate for removal; a/b and a are not considered as deletion candidates, and so never deleted, even if empty (apart from subdirectories).

IMO in this situation, a and b were created by the installation and so should be removed, unless they contain files not added during installation.

----------
type: feature request -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Mon Jun 27 00:50:19 2011
From: report at bugs.python.org (Guy Rozendorn)
Date: Sun, 26 Jun 2011 22:50:19 +0000
Subject: [issue10760] tarfile doesn't handle sysfs well
In-Reply-To: <1293037554.87.0.808780630488.issue10760@psf.upfronthosting.co.za>
Message-ID: <1309128619.51.0.0432266953175.issue10760@psf.upfronthosting.co.za>


Changes by Guy Rozendorn <guy at rzn.co.il>:


----------
nosy: +guyrozendorn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10760>
_______________________________________

From report at bugs.python.org  Mon Jun 27 01:50:47 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 26 Jun 2011 23:50:47 +0000
Subject: [issue12416] packaging does not have hooks callable during
	distribution removal
In-Reply-To: <1309132247.11.0.698244418605.issue12416@psf.upfronthosting.co.za>
Message-ID: <1309132247.11.0.698244418605.issue12416@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

In general it is possible for an installation to make certain system changes other than the record of files written during an installation (for example, under Windows, there may be distribution-specific Windows registry updates).

There seems to be no hook that's called when a distribution is removed, which would allow distribution-specific cleanup code to be called (e.g. to undo Windows registry changes).

Such a hook should be provided.

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 139230
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: normal
severity: normal
status: open
title: packaging does not have hooks callable during distribution removal
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12416>
_______________________________________

From report at bugs.python.org  Mon Jun 27 02:07:52 2011
From: report at bugs.python.org (Graham Dumpleton)
Date: Mon, 27 Jun 2011 00:07:52 +0000
Subject: [issue6531] atexit_callfuncs() crashing within Py_Finalize() when
	using multiple interpreters.
In-Reply-To: <1248175169.79.0.15962102552.issue6531@psf.upfronthosting.co.za>
Message-ID: <1309133272.38.0.294934245444.issue6531@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Segmentation fault. The original description explains the problem is dereferencing of a NULL pointer which has a tendency to invoke such behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6531>
_______________________________________

From report at bugs.python.org  Mon Jun 27 02:29:53 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Jun 2011 00:29:53 +0000
Subject: [issue2377] Replace import.c with a pure Python implementation
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1309134593.21.0.393604816776.issue2377@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
hgrepos: +34

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Mon Jun 27 02:30:41 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Jun 2011 00:30:41 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1309134641.88.0.00675545956392.issue2377@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
title: Replace import.c with a pure Python implementation -> Replace __import__ w/ importlib.__import__

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Mon Jun 27 02:33:10 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Jun 2011 00:33:10 +0000
Subject: [issue8745] zipimport is a bit slow
In-Reply-To: <1274162892.24.0.612432614461.issue8745@psf.upfronthosting.co.za>
Message-ID: <1309134790.97.0.0541432873339.issue8745@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: brett.cannon -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8745>
_______________________________________

From report at bugs.python.org  Mon Jun 27 02:35:09 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Jun 2011 00:35:09 +0000
Subject: [issue8661] FAQ item 2.25 is unclear
In-Reply-To: <1273332822.19.0.471138698588.issue8661@psf.upfronthosting.co.za>
Message-ID: <1309134909.92.0.570247814494.issue8661@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

This is out of date thanks to the rewrite of the FAQ for Mercurial.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8661>
_______________________________________

From report at bugs.python.org  Mon Jun 27 02:35:45 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Jun 2011 00:35:45 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1309134945.02.0.096735621381.issue8912@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: brett.cannon -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Mon Jun 27 02:36:10 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Jun 2011 00:36:10 +0000
Subject: [issue667770] import C API mess
Message-ID: <1309134970.26.0.442098554137.issue667770@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +Replace __import__ w/ importlib.__import__

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue667770>
_______________________________________

From report at bugs.python.org  Mon Jun 27 02:36:52 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Jun 2011 00:36:52 +0000
Subject: [issue7620] Vim syntax highlight
In-Reply-To: <1262445013.64.0.818540648921.issue7620@psf.upfronthosting.co.za>
Message-ID: <1309135012.42.0.973286764491.issue7620@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +Usefulness of the Misc/Vim/ files?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7620>
_______________________________________

From report at bugs.python.org  Mon Jun 27 02:46:18 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Jun 2011 00:46:18 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1309135578.85.0.658089758436.issue2377@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, so first step is to simply replace __import__ w/ importlib.__import__ using builtins.__import__ in order to make sure that all tests pass as expected. Can probably do this by doing the switch in Py_Initialize() somewhere.

Next step after that will be seeing if _io can be used by importlib w/ the import of os postponed until after importlib is bootstrapped.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Mon Jun 27 02:47:02 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 27 Jun 2011 00:47:02 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1309135622.98.0.631865190845.issue2377@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/issue2377>
_______________________________________

From report at bugs.python.org  Mon Jun 27 03:47:24 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 27 Jun 2011 01:47:24 +0000
Subject: [issue6673] Uncaught comprehension SyntaxError eats up all memory
In-Reply-To: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>
Message-ID: <1309139244.13.0.861086076052.issue6673@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The acceptance of PEP 380 actually muddies the waters on this one - the expansion I cited as a syntax error now has a defined meaning. Specifically, list comprehensions containing yield expressions would become generators that return a list (set and dict comprehensions would become generators that return a set or dict, respectively).

Once it is confirmed those semantics are an acceptable outcome of PEP 380's acceptance, this behaviour would be documented in the appropriate locations (likely under the yield expression, with pointers from other parts of the documentation).

----------
type: crash -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6673>
_______________________________________

From report at bugs.python.org  Mon Jun 27 08:50:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Jun 2011 06:50:03 +0000
Subject: [issue11568] docstring of select.epoll.register() is wrong
In-Reply-To: <1300271962.07.0.948411199474.issue11568@psf.upfronthosting.co.za>
Message-ID: <E1Qb5dx-0004Mf-Ez@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0610f70e6694 by Senthil Kumaran in branch '3.2':
Fix closes issue 11568 - update select.epoll.register docstring with mention of correct behavior.
http://hg.python.org/cpython/rev/0610f70e6694

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11568>
_______________________________________

From report at bugs.python.org  Mon Jun 27 08:51:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Jun 2011 06:51:25 +0000
Subject: [issue11568] docstring of select.epoll.register() is wrong
In-Reply-To: <1300271962.07.0.948411199474.issue11568@psf.upfronthosting.co.za>
Message-ID: <E1Qb5fH-0004Y0-NN@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a6586cb660dc by Senthil Kumaran in branch '2.7':
Fix closes issue 11568 - update select.epoll.register docstring with mention of correct behavior.
http://hg.python.org/cpython/rev/a6586cb660dc

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11568>
_______________________________________

From report at bugs.python.org  Mon Jun 27 08:54:04 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 27 Jun 2011 06:54:04 +0000
Subject: [issue11568] docstring of select.epoll.register() is wrong
In-Reply-To: <1309101150.64.0.082995361798.issue11568@psf.upfronthosting.co.za>
Message-ID: <20110627065359.GA14974@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

On Sun, Jun 26, 2011 at 03:12:30PM +0000, Sandro Tosi wrote:
> The patch is fine: but would you be interested in trying to write a
> unittest for select.epoll.register ? it would be really nice to

This is covered in test_epoll.py

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11568>
_______________________________________

From report at bugs.python.org  Mon Jun 27 09:14:33 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 27 Jun 2011 07:14:33 +0000
Subject: [issue11568] docstring of select.epoll.register() is wrong
In-Reply-To: <1300271962.07.0.948411199474.issue11568@psf.upfronthosting.co.za>
Message-ID: <1309158873.7.0.388539057429.issue11568@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Ah, I find the test file name a bit unhappy (why not test select.epoll in test_select? or add select in the filename?) but since it's covered - I'm fine! :) Next time I'll grep instead of simple file glob - thanks for your help, Senthil.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11568>
_______________________________________

From report at bugs.python.org  Mon Jun 27 09:29:52 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Mon, 27 Jun 2011 07:29:52 +0000
Subject: [issue1475523] gettext breaks on plural-forms header
Message-ID: <1309159792.13.0.384385724987.issue1475523@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

This looks similar to https://bugs.gentoo.org/show_bug.cgi?id=373115. Is it the same thing, or should I file a separate bug for it? (Sorry, I don't intend to hijack this bug, but I don't know much about gettext and the patch here looks somewhat similar to the patch proposed there.)

----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1475523>
_______________________________________

From report at bugs.python.org  Mon Jun 27 09:31:43 2011
From: report at bugs.python.org (Paul Hildebrandt)
Date: Mon, 27 Jun 2011 07:31:43 +0000
Subject: [issue12417] Inappropriate copyright on profile files
In-Reply-To: <1309159902.95.0.523889608619.issue12417@psf.upfronthosting.co.za>
Message-ID: <1309159902.95.0.523889608619.issue12417@psf.upfronthosting.co.za>


New submission from Paul Hildebrandt <paul_hildebrandt at yahoo.com>:

profile.py and pstats.py have an inappropriate copyright for some.  These files were contributed by a company that was acquired by Disney.  I have a patch that has passed Disney legal to resolve the problem.

The following is the cogent part of a conversation between Matthias Klose and myself.  He is including information about the issue:

 http://mail.python.org/pipermail/python-dev/2005-February/051450.html

"""
The current license for the Python profiler is not conforming to the
DFSG
(Debian free software guidelines).

http://www.python.org/doc/current/lib/node829.html states

 "This permission is explicitly restricted to the copying and
 modification of the software to remain in Python, compiled Python,
 or other languages (such as C) wherein the modified or derived code
 is exclusively imported into a Python module."

The DFSG,
http://www.debian.org/doc/debian-policy/ch-archive.html#s-dfsg,
third paragraph state:

 "Derived Works
   The license must allow modifications and derived works, and must
   allow them to be distributed under the same terms as the license
   of the original software."

- Does somebody knows about the history of this license, why it is
 more restricted than the Python license?
- Is there a chance to change the license for these two modules
 (profile.py, pstats.py)?
"""

----------
components: Library (Lib)
messages: 139240
nosy: Paul.Hildebrandt
priority: normal
severity: normal
status: open
title: Inappropriate copyright on profile files

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12417>
_______________________________________

From report at bugs.python.org  Mon Jun 27 09:33:22 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Mon, 27 Jun 2011 07:33:22 +0000
Subject: [issue5375] Unified locals/consts array + register-based instructions
In-Reply-To: <1235657334.5.0.583024676615.issue5375@psf.upfronthosting.co.za>
Message-ID: <1309160002.06.0.105034393447.issue5375@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Yeah, I probably won't work on this anytime soon. I think this has also become less interesting as pypy has made progress.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5375>
_______________________________________

From report at bugs.python.org  Mon Jun 27 09:41:31 2011
From: report at bugs.python.org (Paul Hildebrandt)
Date: Mon, 27 Jun 2011 07:41:31 +0000
Subject: [issue12417] Inappropriate copyright on profile files
In-Reply-To: <1309159902.95.0.523889608619.issue12417@psf.upfronthosting.co.za>
Message-ID: <1309160491.69.0.873694261795.issue12417@psf.upfronthosting.co.za>


Paul Hildebrandt <paul_hildebrandt at yahoo.com> added the comment:

This is the patch. It was created with

hg diff >WDAS.patch

at the root of the hg repository.  

This patch is just a comment change and should apply to versions of Python currently being update.

----------
keywords: +patch
resolution:  -> fixed
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file22491/WDAS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12417>
_______________________________________

From report at bugs.python.org  Mon Jun 27 10:05:05 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 27 Jun 2011 08:05:05 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <BANLkTimA4JZa6qWb1TUan=YLgK0s9TKxdQ@mail.gmail.com>
Message-ID: <4E0839AF.2090106@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> That would be incorrect for some systems. For example, FreeBSD does
>> change sets of symbolic constants across system releases (mostly
>> additions, but sometimes also removals). Back then, SunOS 4 and SunOS
>> 5 were completely unrelated systems.
>>
> 
> Well, I don't see the problem in that case.

What I'm advocating is to special-case Linux (and any other system
where major version numbers don't mean much).

> The point I (and others) have been trying to make is that 99% of the
> time, people using sys.platform really mean platform.system() or
> uname[0], since they're only interested in the operating system, and
> don't care about the release. That's true of the vast majority of such
> occurrences in Lib/test, and probably true of the vast majority of the
> user code base.

I don't argue with that. I agree the code is broken (although I disagree
that platform.system is the right answer in most cases), but that
doesn't help resolving this issue (unless the resolution is "no change",
which I still oppose to).

> Furthermore, at least on Linux, the major version number doesn't mean
> anything

Indeed - hence I propose to drop it from sys.platform if the system
is Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Jun 27 10:12:24 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 27 Jun 2011 08:12:24 +0000
Subject: [issue1475523] gettext breaks on plural-forms header
Message-ID: <1309162344.46.0.186324379039.issue1475523@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It's difficult to tell whether it's the same thing. Is the po file in question available readily for inspection?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1475523>
_______________________________________

From report at bugs.python.org  Mon Jun 27 10:30:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Jun 2011 08:30:11 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1309014947.24.0.941872043265.issue6721@psf.upfronthosting.co.za>
Message-ID: <20110627103005.2598947f@msiwind>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If there's agreement that the general problem is unsolvable (so fork and
> threads just don't get along with each other), what we could attempt is
> trying to limit the side effects in the standard library, so that fewest
> users as possible are affected by this problem.

Actually, I think Charles-Fran?ois' suggested approach is a good one.

> For instance, having deadlocks just because of print statements sounds
> like a bad QoI that we could attempt to improve. Is there a reason while
> BufferedIO needs to hold its internal data-structure lock (used to make
> it thread-safe) while it's doing I/O and releasing the GIL? I would think
> that it's feasible to patch it so that its internal lock is only used to
> synchronize accesses to the internal data structures, but it is never
> held while I/O is performed (and thus the GIL is released -- at which
> point, if another threads forks, the problem appears).

Not really. Whether you update the internal structures depends on the
result of the I/O (so that e.g. two threads don't flush the same buffer
simultaneously).

Also, finer-grained locking is always a risky endeavour and we already have
a couple of bugs to fix in the current buffered I/O implementation :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Mon Jun 27 10:32:00 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Mon, 27 Jun 2011 08:32:00 +0000
Subject: [issue1475523] gettext breaks on plural-forms header
Message-ID: <1309163520.15.0.819813962183.issue1475523@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Looks like this was the problem: http://git.fedorahosted.org/git/?p=virt-manager.git;a=commitdiff;h=cb56316cf3702f03b05e30f406ff3028e45f7bfb.

E.g., the empty Plural-Forms header is throwing off the python gettext parser.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1475523>
_______________________________________

From report at bugs.python.org  Mon Jun 27 10:35:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Jun 2011 08:35:34 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1309117743.5.0.873853952026.issue12291@psf.upfronthosting.co.za>
Message-ID: <20110627103528.5c9866b6@msiwind>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le Sun, 26 Jun 2011 19:49:03 +0000,
Vinay Sajip <report at bugs.python.org> a ?crit :
> 
> Added file: http://bugs.python.org/file22487/0feab4e7b27f.diff

Just a nit, could you give descriptive file names to your patches?
Hex numbers quickly get confusing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Mon Jun 27 10:39:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Jun 2011 08:39:52 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <4E0839AF.2090106@v.loewis.de>
Message-ID: <20110627103946.13f4cd1d@msiwind>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le Mon, 27 Jun 2011 08:05:05 +0000,
Martin v. L?wis <report at bugs.python.org> a ?crit :
> 
> What I'm advocating is to special-case Linux (and any other system
> where major version numbers don't mean much).

Actually, it would itself break compatibility, because sys.platform would
jump from "linux2" to "linux" from one Python release to another. It would
therefore only be applicable, at best, to 3.3.

I think we should at least document the idiom of using
"sys.platform.startswith(...)", and mention the platform module as an
alternative. This can be done in all doc versions without breaking
anything, and in time for Linux 3 :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Jun 27 10:45:43 2011
From: report at bugs.python.org (Stefan Schwarzer)
Date: Mon, 27 Jun 2011 08:45:43 +0000
Subject: [issue1067702] urllib fails with multiple ftp transfers
Message-ID: <1309164343.54.0.647232997116.issue1067702@psf.upfronthosting.co.za>


Stefan Schwarzer <sschwarzer at sschwarzer.net> added the comment:

Hi Senthil,

I don't yet understand what was going on before it resulted in the traceback. I also don't understand _why_ the patch fixes _this_ bug. (That's not to say it doesn't, but I think it's not obvious either. :-) )

Were you able to reproduce the exception with my attached script before you did the change? Here in the hotel I have a much faster internet connection than I had yesterday at the sprint (where lots of people shared the uplink), and now I can't reproduce the exception after running the test script three times, even _without_ having your change applied.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1067702>
_______________________________________

From report at bugs.python.org  Mon Jun 27 10:48:26 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Mon, 27 Jun 2011 08:48:26 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1309164506.27.0.504874091056.issue12291@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Mon Jun 27 10:52:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Jun 2011 08:52:10 +0000
Subject: [issue5375] Unified locals/consts array + register-based instructions
In-Reply-To: <1235657334.5.0.583024676615.issue5375@psf.upfronthosting.co.za>
Message-ID: <1309164730.09.0.408907243159.issue5375@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> postponed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5375>
_______________________________________

From report at bugs.python.org  Mon Jun 27 11:17:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Jun 2011 09:17:58 +0000
Subject: [issue12139] Add CCC command support to ftplib
In-Reply-To: <1306001340.71.0.345746598563.issue12139@psf.upfronthosting.co.za>
Message-ID: <E1Qb7x7-0007ht-5P@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d2eacbbdaf57 by Giampaolo Rodola' in branch 'default':
Issue 12139: add CCC command support to FTP_TLS class to revert the SSL connection back to clear-text.
http://hg.python.org/cpython/rev/d2eacbbdaf57

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12139>
_______________________________________

From report at bugs.python.org  Mon Jun 27 11:18:39 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 27 Jun 2011 09:18:39 +0000
Subject: [issue12139] Add CCC command support to ftplib
In-Reply-To: <1306001340.71.0.345746598563.issue12139@psf.upfronthosting.co.za>
Message-ID: <1309166319.29.0.997674082109.issue12139@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12139>
_______________________________________

From report at bugs.python.org  Mon Jun 27 11:35:49 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 27 Jun 2011 09:35:49 +0000
Subject: [issue1475523] gettext breaks on plural-forms header
Message-ID: <1309167349.89.0.213712553098.issue1475523@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/issue1475523>
_______________________________________

From report at bugs.python.org  Mon Jun 27 11:40:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jun 2011 09:40:16 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <1309167616.46.0.691982290636.issue12400@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Typical example: (... smtplib ...)

Another example (yesterday):
------
[355/356/2] test_subprocess
...
Re-running test test_subprocess in verbose mode
...
Ran 228 tests in 322.313s

OK (skipped=20)
------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Mon Jun 27 11:58:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jun 2011 09:58:00 +0000
Subject: [issue12139] Add CCC command support to ftplib
In-Reply-To: <1306001340.71.0.345746598563.issue12139@psf.upfronthosting.co.za>
Message-ID: <1309168680.68.0.835876657164.issue12139@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%203.x/builds/4043/steps/test/logs/stdio

======================================================================
ERROR: test_ccc (test.test_ftplib.TestTLS_FTPClass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_ftplib.py", line 890, in test_ccc
    self.client.sendcmd('noop')
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/ftplib.py", line 261, in sendcmd
    return self.getresp()
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/ftplib.py", line 236, in getresp
    raise error_proto(resp)
ftplib.error_proto: 
 ?x???
?????qh???c??\?9??
#???200 noop ok

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12139>
_______________________________________

From report at bugs.python.org  Mon Jun 27 11:58:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jun 2011 09:58:22 +0000
Subject: [issue12139] Add CCC command support to ftplib
In-Reply-To: <1306001340.71.0.345746598563.issue12139@psf.upfronthosting.co.za>
Message-ID: <1309168702.66.0.967526966196.issue12139@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x/builds/2792/steps/test/logs/stdio

======================================================================
ERROR: test_ccc (test.test_ftplib.TestTLS_FTPClass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_ftplib.py", line 890, in test_ccc
    self.client.sendcmd('noop')
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/ftplib.py", line 261, in sendcmd
    return self.getresp()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/ftplib.py", line 226, in getresp
    resp = self.getmultiline()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/ftplib.py", line 212, in getmultiline
    line = self.getline()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/ftplib.py", line 199, in getline
    line = self.file.readline()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/socket.py", line 279, in readinto
    return self._sock.recv_into(b)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/ssl.py", line 392, in recv_into
    return socket.recv_into(self, buffer, nbytes, flags)
socket.timeout: timed out

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12139>
_______________________________________

From report at bugs.python.org  Mon Jun 27 12:01:30 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 27 Jun 2011 10:01:30 +0000
Subject: [issue12139] Add CCC command support to ftplib
In-Reply-To: <1306001340.71.0.345746598563.issue12139@psf.upfronthosting.co.za>
Message-ID: <1309168890.12.0.606160866386.issue12139@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Hmm... Reopening. I'll look into this later.

----------
resolution: fixed -> 
status: closed -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12139>
_______________________________________

From report at bugs.python.org  Mon Jun 27 12:16:24 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 27 Jun 2011 10:16:24 +0000
Subject: [issue12376] unittest.TextTestResult.__init__ does not pass on its
	init arguments in super call
In-Reply-To: <1308591554.84.0.206840920137.issue12376@psf.upfronthosting.co.za>
Message-ID: <1309169784.13.0.488204530458.issue12376@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I have a feeling I added the arguments to TestResult.__init__ to allow it to be used as a silent test result directly in place of TextTestResult. I still need to check this. 

Not adding the arguments to the super call in TextTestResult would have been an oversight. Let me check this understanding is correct, and if there is no reason for it not to pass on those arguments I'll fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12376>
_______________________________________

From report at bugs.python.org  Mon Jun 27 12:16:38 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 27 Jun 2011 10:16:38 +0000
Subject: [issue12376] unittest.TextTestResult.__init__ does not pass on its
	init arguments in super call
In-Reply-To: <1308591554.84.0.206840920137.issue12376@psf.upfronthosting.co.za>
Message-ID: <1309169798.55.0.0147925229384.issue12376@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
assignee:  -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12376>
_______________________________________

From report at bugs.python.org  Mon Jun 27 12:32:49 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 27 Jun 2011 10:32:49 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1309170769.89.0.652203395529.issue10181@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Nick, you know a lot about this issue and I'm probably missing many things
here. I misunderstood your concept of PyManagedBuffer, so my previous
posting might have been hard to understand.

I'd appreciate if you (or anyone in this thread) could comment if the
following would work *in theory*, even if you are against an additional
getslicedbufferproc:


As I understand, there are two major issues that complicate the code:

  1) the copying in PyMemoryView_FromBuffer()
  2) slicing


To address 1), I wanted to create new memoryview objects exclusively
from proper base objects that implement the buffer protocol. So the
plan was to create small wrapper object inside PyMemoryView_FromBuffer()
that handles enough of the buffer protocol to be usable inside the stdlib
for one-dimensional objects. The actual memoryview would then be created
by calling PyMemoryView_FromObject() on that wrapper.

[PyMemoryView_FromObject() would then obviously not call PyMemoryView_FromBuffer(),
but would create the view directly.]


To address 2), buffers would *always* have to be filled in by the original
exporting object, hence the proposal to add a getslicedbufferproc.

Then memoryview would always have a proper base object and could always call
getbuffer()/INCREF(base) and releasebuffer()/DECREF(base). I thought this would
make the code much cleaner.


> Direct: the view is directly accessing an underlying object via the PEP 3118 API
> Indirect: the view has a reference to another memoryview object that it is using
>           as a data source

Is there still a difference if only the original base object manages buffers
and they are never copied?


> This is better than requiring that every implementor of the buffer API
> worry about the slicing logic - we can do it right in memoryview and then
> implementers of producer objects don't have to worry about it.

I'm not sure, but my reasoning was that e.g. in numpy the slicing logic
is already in place. Then again, I don't know if it is a legitimate use
of buf, shapes and strides to implement slicing.

According to this mail, slicing information was supposed to be
part of the memoryview struct:

http://mail.python.org/pipermail/python-dev/2007-April/072584.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Jun 27 13:28:13 2011
From: report at bugs.python.org (Pauli Virtanen)
Date: Mon, 27 Jun 2011 11:28:13 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1309174093.79.0.141565096932.issue10181@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

skrah writes:
> I think slicing (esp. multidimensional slicing) would be greatly
> simplified if we added a requirement for the *exporting* object
> to provide a sliced view. (The same applies to sub-views, also
> see source comments below [1]).
>
> For example, an exporting object could provide a sliced view by adding 
> a getslicedbufferproc to PyBufferProcs:
>
> int PyObject_GetSlicedBuffer(PyObject *obj, Py_buffer *view, 
>                              int flags, PyObject *key);

The same thing can be done via

    PyObject_GetBuffer(obj, &view, flags);
    PyBuffer_Slice(&view, &sliced_view, flags, key);

given an implementation of PyBuffer_Slice. The logic in PyBuffer_Slice does not depend on where the buffer comes from, and every buffer can be sliced.

As far as I see, the advantage of `getslicedbufferproc` would be to make the implementation of PyMemoryView simpler, but not much else. In my view, having each exporter implement the same logic by itself would only be an unnecessary burden.

>  o The invariant that all allocated memory in the buffer belongs
>    to the exporting object remains intact.

Numpy arrays do not have this invariant, and they happily re-export memory owned by someone else. This is one root of problems here: the PEP implicitly assumes that re-exporting buffers (e.g. memoryview's implementation of `getbuffer`) is done in the way Numpy does it. Because of this, there is no mechanism for "incrementing the refcount" of an existing buffer export. Maintaining the above invariant then unavoidably leads to strange behavior in corner cases (which probably are very rare, as mentioned above), and as happened here, make the implementation messy and lead to bugs.

The invariant *is* required for guaranteeing that `memoryview.release()` always succeeds. Such a method probably wasn't foreseen in the PEP (and I did not remember that it existed in my first patch), as Numpy arrays don't have any equivalent. The alternatives here are (i) do as Numpy does and give up the invariant and allow `.release()` to fail in some cases, or (ii) document the corner cases in the interface spec and try to detect them and fail if they occur. Which of these is chosen probably does not matter much in practice, but having PyManagedBuffer will make implementing either choice easier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Jun 27 13:47:44 2011
From: report at bugs.python.org (Vincent Legoll)
Date: Mon, 27 Jun 2011 11:47:44 +0000
Subject: [issue11302] Add more tests to test_ast.py
In-Reply-To: <1298496457.65.0.147228634144.issue11302@psf.upfronthosting.co.za>
Message-ID: <1309175264.13.0.413472624706.issue11302@psf.upfronthosting.co.za>


Vincent Legoll <vincent.legoll at gmail.com> added the comment:

OK I'll look at it and respin with the comments in mind

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11302>
_______________________________________

From report at bugs.python.org  Mon Jun 27 14:02:19 2011
From: report at bugs.python.org (Steve Langasek)
Date: Mon, 27 Jun 2011 12:02:19 +0000
Subject: [issue12418] python should inherit the library search path from the
	compiler for stdlib extensions
In-Reply-To: <1309176139.38.0.221668771682.issue12418@psf.upfronthosting.co.za>
Message-ID: <1309176139.38.0.221668771682.issue12418@psf.upfronthosting.co.za>


New submission from Steve Langasek <steve.langasek at ubuntu.com>:

related to http://bugs.python.org/issue11715

python 2.7 and 3.1 now include a patch for behavior specific to Ubuntu and Debian to search in multiarch directories for libraries needed for building stdlib extensions.

This distro-specific patch is unnecessary if instead python could just query and use the default search path from the compiler.

With gcc, it's possible to query the list of built-in library directories with:

$ gcc -print-search-dirs | sed -n -e's/libraries: =//p' | sed -e's/:/\n/g' | xargs -n1 readlink -f

and the include directories with:

$ gcc -v -E - < /dev/null 2>&1 | awk '/^#include/,/^End of search/ {i=1} i==1 && /^ / {print}'

(additional filtering, to exclude compiler-internal directories, may be sensible.)

Having python query and use these directories when searching for libraries would make the build system more robust in a variety of circumstances.

----------
components: Build
messages: 139259
nosy: vorlon
priority: normal
severity: normal
status: open
title: python should inherit the library search path from the compiler for stdlib extensions
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12418>
_______________________________________

From report at bugs.python.org  Mon Jun 27 14:27:57 2011
From: report at bugs.python.org (Floris Bruynooghe)
Date: Mon, 27 Jun 2011 12:27:57 +0000
Subject: [issue12419] Add ident parameter to SysLogHandler
In-Reply-To: <1309177677.59.0.756868126424.issue12419@psf.upfronthosting.co.za>
Message-ID: <1309177677.59.0.756868126424.issue12419@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

It would be nice if the SysLogHandler also accepted an "ident" parameter in line with the syslog.openlog() function.  This simply prepends the string passed in as "ident" to each log message which currently needs to be implemented with a log filter which modifies the record.

----------
components: Library (Lib)
messages: 139260
nosy: flub
priority: normal
severity: normal
status: open
title: Add ident parameter to SysLogHandler
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12419>
_______________________________________

From report at bugs.python.org  Mon Jun 27 14:28:22 2011
From: report at bugs.python.org (Floris Bruynooghe)
Date: Mon, 27 Jun 2011 12:28:22 +0000
Subject: [issue12419] Add ident parameter to SysLogHandler
In-Reply-To: <1309177677.59.0.756868126424.issue12419@psf.upfronthosting.co.za>
Message-ID: <1309177702.75.0.290627721954.issue12419@psf.upfronthosting.co.za>


Changes by Floris Bruynooghe <floris.bruynooghe at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12419>
_______________________________________

From report at bugs.python.org  Mon Jun 27 14:33:17 2011
From: report at bugs.python.org (Henry Precheur)
Date: Mon, 27 Jun 2011 12:33:17 +0000
Subject: [issue12420] distutils crashes if PATH is not defined
In-Reply-To: <1309177997.74.0.17903211546.issue12420@psf.upfronthosting.co.za>
Message-ID: <1309177997.74.0.17903211546.issue12420@psf.upfronthosting.co.za>


New submission from Henry Precheur <henry at precheur.org>:

The function find_executable crashes if PATH is not defined.

I admit that it's an extreme case, but it's probably better to on the safe side of things.

What about using the current directory only if PATH is not defined? This seems to be a reasonable workaround.

----------
assignee: tarek
components: Distutils, Distutils2
files: fix_empty_path.diff
keywords: patch
messages: 139261
nosy: alexis, eric.araujo, henry.precheur, tarek
priority: normal
severity: normal
status: open
title: distutils crashes if PATH is not defined
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file22492/fix_empty_path.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12420>
_______________________________________

From report at bugs.python.org  Mon Jun 27 14:41:07 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 27 Jun 2011 12:41:07 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1309178467.16.0.489461001132.issue12291@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Just a nit, could you give descriptive file names to your patches?
> Hex numbers quickly get confusing.

Ok - I was under the impression that those names were generated automatically from the changeset hash, and that changing the name arbitrarily would break something. Is it not better/sufficient if I just update the description?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Mon Jun 27 14:43:58 2011
From: report at bugs.python.org (Henry Precheur)
Date: Mon, 27 Jun 2011 12:43:58 +0000
Subject: [issue12401] unset PYTHON* environment variables when running tests
In-Reply-To: <1308952676.91.0.708236346954.issue12401@psf.upfronthosting.co.za>
Message-ID: <1309178638.59.0.78900925697.issue12401@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

Here's a small patch to call regression tests without any environment variable defined. It's probably a good thing to run all the tests with a clean state, this way they are less likely to fail for mysterious external reasons. For example test_displayhook_unencodable was failing because I was overriding displayhook in my PYTHONSTARTUP file.

On the other hand, some problems with environment variables might go unnoticed. But I don't think there's much risk.

Note that test_distutils will fail with this patch if #12420 is not taken care of beforehand.

----------
keywords: +patch
Added file: http://bugs.python.org/file22493/empty_environment.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12401>
_______________________________________

From report at bugs.python.org  Mon Jun 27 14:53:37 2011
From: report at bugs.python.org (Henry Precheur)
Date: Mon, 27 Jun 2011 12:53:37 +0000
Subject: [issue12421] Use PYTHON when calling Parser/asdl_c.py
In-Reply-To: <1309179217.52.0.471772835314.issue12421@psf.upfronthosting.co.za>
Message-ID: <1309179217.52.0.471772835314.issue12421@psf.upfronthosting.co.za>


New submission from Henry Precheur <henry at precheur.org>:

Parser/asdl_c.py uses `/usr/bin/env python' as an interpreter. But Python executable is not always `python'. With OpenBSD's ports, CPython's interpreters are installed as pythonX.Y. There's a variable PYTHON in the Makefile, that's what should be used.

This way make PYTHON=python2.7 works on OpenBSD.

The attached patch fixes that.

Note that the executable bit and the hashbang can be removed from asdl_c.py if the patch is applied.

----------
components: Build
files: fix_ASDLGEN.diff
keywords: patch
messages: 139264
nosy: henry.precheur
priority: normal
severity: normal
status: open
title: Use PYTHON when calling Parser/asdl_c.py
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file22494/fix_ASDLGEN.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12421>
_______________________________________

From report at bugs.python.org  Mon Jun 27 14:59:56 2011
From: report at bugs.python.org (sorin)
Date: Mon, 27 Jun 2011 12:59:56 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1309179596.93.0.439706579986.issue12398@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

Here is a test file that will replicate the problem, I added it as a gist so it could support contributions ;)

Py <2.7 works
Py ==2.7 fails
Py >=3.0 works after minor changes required by py3k

https://gist.github.com/1047551

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12398>
_______________________________________

From report at bugs.python.org  Mon Jun 27 15:17:56 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 27 Jun 2011 13:17:56 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1309180676.88.0.541176207355.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'll try to do a summary of the conversation so far, since it's quite long and hard to follow.

The basic issue is that memoryview needs to support copying and slicing that creates a new memoryview object. The major problem with that is that the PEP 3118 semantics as implemented operate in such a way that neither copying the Py_buffer struct *nor* requesting a new copy of the struct from the underlying object will do the right thing in all cases. (According to the PEP *as written* copying probably should have been OK, but the implementation doesn't match the PEP in several important respects such that copying is definitely wrong in the absence of tight control of the lifecycles of copies relative to the original).

Therefore, we either need to redesign the buffer export from memoryview to use daisy chaining (such that in "m = memoryview(obj); m2 = m[:]; m3 = m2[:]" m3 references m2 which references m which in turn references obj) or else we need to introduce an internal reference counted object (PyManagedBuffer) which allows a single view of an underlying object to be safely shared amongst multiple clients (such that m, m2 and m3 would all reference the same managed buffer instance which holds the reference to obj). My preference is strongly for the latter approach as it prevents unbounded and wasteful daisy chaining while also providing a clean, easy to use interface that will make it easier for 3rd parties to write PEP 3118 API consumers (by using PyManagedBuffer instead of the raw Py_buffer struct).

Once that basic lifecycle problem for the underlying buffers is dealt with then we can start worrying about other problems like exporting Py_buffer objects from memoryview instances correctly. The lifecycle problem is unrelated to the details of the buffer *contents* though - it's entirely about the fact that clients can't safely copy all those pointers (as some may refer to addresses inside the struct) and asking the original object for a fresh copy is permitted to return a different answer each time.

The actual *slicing* code in memoryview isn't too bad - it just needs to use dedicated storage rather than messing with the contents of the Py_buffer struct it received from the underlying object. Probably the easiest way to handle that is by having the PyManagedBuffer reference be in *addition* to the current Py_buffer struct in the internal state - then the latter can be used to record the effects of the slicing, if any. Because we know the original Py_buffer struct is guaranteed to remain alive and unmodified, we don't need to worry about fiddling with any copied pointers - we can just leave them pointing into the original structure.

When accessed via the PEP 3118 API, memoryview objects would then export that modified Py_buffer struct rather than the original one (so daisychaining would be possible, but we wouldn't make it easy to do from pure Python code, as both the memoryview constructor and slicing would give each new memoryview object a reference to the original managed buffer and just update the internal view details as appropriate.

Here's the current MemoryView definition:

typedef struct {
    PyObject_HEAD
    Py_buffer view;
} PyMemoryViewObject;

The TL;DR version of the above is that I would like to see it become:

typedef struct {
    PyObject_HEAD
    PyManagedBuffer source_data; // shared read-only Py_buffer access
    Py_buffer view;  // shape, strides, etc potentially modified
} PyMemoryViewObject;

Once the internal Py_buffer had been initialised, the memoryview code actually wouldn't *use* the source data reference all that much (aside from eventually releasing the buffer, it wouldn't use it at all). Instead, that reference would be retained solely to control the lifecycle of the original Py_buffer object relative to the modified copies in the various memoryview instances.

Does all that make my perspective any clearer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Jun 27 15:24:03 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 27 Jun 2011 13:24:03 +0000
Subject: [issue12419] Add ident parameter to SysLogHandler
In-Reply-To: <1309177677.59.0.756868126424.issue12419@psf.upfronthosting.co.za>
Message-ID: <1309181043.97.0.135944076671.issue12419@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12419>
_______________________________________

From report at bugs.python.org  Mon Jun 27 15:30:18 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Jun 2011 13:30:18 +0000
Subject: [issue12421] Use PYTHON when calling Parser/asdl_c.py
In-Reply-To: <1309179217.52.0.471772835314.issue12421@psf.upfronthosting.co.za>
Message-ID: <1309181418.2.0.445130717099.issue12421@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't believe we have any desire to support unix systems that do not define 'python', and 'python3' executables in the path.  If the distribution wishes to do that they'll have to patch everything to accommodate it.

That however is mostly irrelevant to this case.  asdl_c.py is not needed for building python.  The files it generates are already generated and included in the release tarballs, and in the release tarballs the file timestamps should be such that asdl_c.py is not invoked.  (When working from a checkout this may not be true due to vcs tool file timestamp issues; you just have to touch the files manually in that case.)  When the file *is* run, it is not the python being built that is used to run it, it is an already existing python.  So using the PYTHON variable in the Makefile would be incorrect.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12421>
_______________________________________

From report at bugs.python.org  Mon Jun 27 15:37:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Jun 2011 13:37:25 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1309181845.26.0.666661286511.issue12398@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

rdmurray>python2.6 py27-str-unicode-bytes.py 
type(b)=<type 'str'>
Traceback (most recent call last):
  File "py27-str-unicode-bytes.py", line 17, in <module>
    unicode_str += b # this line will throw UnicodeDecodeError on Python 2.7
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 4: ordinal not in range(128)

And of course it doesn't work earlier than 2.6 since the b'' notation isn't supported before 2.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12398>
_______________________________________

From report at bugs.python.org  Mon Jun 27 15:38:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jun 2011 13:38:59 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1309181939.73.0.381272894928.issue12398@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/issue12398>
_______________________________________

From report at bugs.python.org  Mon Jun 27 15:41:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Jun 2011 13:41:38 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1309182098.63.0.843789113055.issue12398@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

To clarify: if I convert your program to using strings pre2.6, it still fails with a UnicodeDecodeError, as one would expect.  bytes are strings in 2.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12398>
_______________________________________

From report at bugs.python.org  Mon Jun 27 15:46:47 2011
From: report at bugs.python.org (Henry Precheur)
Date: Mon, 27 Jun 2011 13:46:47 +0000
Subject: [issue12421] Use PYTHON when calling Parser/asdl_c.py
In-Reply-To: <1309179217.52.0.471772835314.issue12421@psf.upfronthosting.co.za>
Message-ID: <1309182407.3.0.545802440789.issue12421@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

Indeed, I didn't realize that PYTHON was the name of the target interpreter and not the name a an already installed interpreter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12421>
_______________________________________

From report at bugs.python.org  Mon Jun 27 15:48:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Jun 2011 13:48:17 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1309182497.42.0.0962898413879.issue12398@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

And finally, your program does *not* succeed on Python3, except in the trivial sense that on python3 you never attempt to add the string and bytes data.  It is exactly this kind of programming error that Python3 is designed to avoid: instead of sometimes getting a UnicodeDecodeError depending on what is in the "bytes" string, you *always* get a "Can't convert 'bytes' object to str implicitly" error when you attempt to add string and bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12398>
_______________________________________

From report at bugs.python.org  Mon Jun 27 15:53:51 2011
From: report at bugs.python.org (sorin)
Date: Mon, 27 Jun 2011 13:53:51 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1309182831.75.0.81182143822.issue12398@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

Right, so you have some binary data and you want to sent it to `httplib`. This worked in the past when `msg` was a non-unicode string, but starting with Python 2.7 this became an unicode string, so when you try to append the `message` if will fail because it will try to decode it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12398>
_______________________________________

From report at bugs.python.org  Mon Jun 27 15:54:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 13:54:03 +0000
Subject: [issue12420] distutils crashes if PATH is not defined
In-Reply-To: <1309177997.74.0.17903211546.issue12420@psf.upfronthosting.co.za>
Message-ID: <1309182843.05.0.0203447338667.issue12420@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Can you tell how you ran into this?  Did you call the function directly, or did you get the bug while running a setup.py command?  Also, what do you mean by crash?  We use that for CPython segmentation faults, not regular misbehavior.  If you could attach the exact command or script that triggered the bug and the full traceback, it would help.

I don?t think using the current directory is a good idea: it?s a security hazard.

----------
assignee: tarek -> eric.araujo
type:  -> behavior
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12420>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:06:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 14:06:13 +0000
Subject: [issue12416] packaging does not have hooks callable during
	distribution removal
In-Reply-To: <1309132247.11.0.698244418605.issue12416@psf.upfronthosting.co.za>
Message-ID: <1309183573.58.0.946383918343.issue12416@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have no objection, but you may want to ask on the fellowship ML first.

Should the hooks be run before the removal or just after?  (Debian for example has both, which makes four hooks: preinst, postinst, prerm, postrm).  Our setup_hooks (used with pysetup commands) are run right after the setup.cfg file is parsed, before any operation is started.

Regarding implementation: The hook should be defined in the global section of setup.cfg; upon installation, packaging would write this info into the dist-info directory (say in an UNINSTALLHOOKS file), which would be read when preparing an uninstallation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12416>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:07:03 2011
From: report at bugs.python.org (Vincent Legoll)
Date: Mon, 27 Jun 2011 14:07:03 +0000
Subject: [issue11302] Add more tests to test_ast.py
In-Reply-To: <1298496457.65.0.147228634144.issue11302@psf.upfronthosting.co.za>
Message-ID: <1309183623.48.0.0160129294788.issue11302@psf.upfronthosting.co.za>


Vincent Legoll <vincent.legoll at gmail.com> added the comment:

Here we are, I left the exact messages for raised exceptions as comments so they can easily be checked in case of test failure...

Does that look OK ?

----------
Added file: http://bugs.python.org/file22495/add-more-tests-for-ast_py-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11302>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:07:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 14:07:55 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1308995950.75.0.288905614048.issue12406@psf.upfronthosting.co.za>
Message-ID: <1309183675.93.0.264189185703.issue12406@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I've realised there are more additions due to packaging - for example
> there is a whole set of "wininst-X.Y[-amd64].exe" files

Oh thanks, I had forgotten about msi.py.  Copying the similar section that already exists for distutils wininst executables and adding the two files added for packaging should do the trick.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12406>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:10:12 2011
From: report at bugs.python.org (Henry Precheur)
Date: Mon, 27 Jun 2011 14:10:12 +0000
Subject: [issue12420] distutils crashes if PATH is not defined
In-Reply-To: <1309182843.05.0.0203447338667.issue12420@psf.upfronthosting.co.za>
Message-ID: <20110627141009.GA733@onion.novuscom.net>


Henry Precheur <henry at precheur.org> added the comment:

Sorry "crash" wasn't the right term. It's just that distutils tests fail.

I ran into that when trying to run unit tests without any environment
variable (see #12401).

$ env -i ./python ./Lib/test/regrtest.py test_distutils
[1/1] test_distutils
test test_distutils crashed -- Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 987, in runtest_inner
  File "/home/henry/code/cpython/Lib/test/test_distutils.py", line 13, in test_main
    test.support.run_unittest(distutils.tests.test_suite())
  File "/home/henry/code/cpython/Lib/distutils/tests/__init__.py", line 29, in test_suite
    __import__(modname)
  File "/home/henry/code/cpython/Lib/distutils/tests/test_archive_util.py", line 33, in <module>
    unittest.TestCase):
  File "/home/henry/code/cpython/Lib/distutils/tests/test_archive_util.py", line 96, in ArchiveUtilTestCase
    @unittest.skipUnless(find_executable('tar') and find_executable('gzip')
  File "/home/henry/code/cpython/Lib/distutils/spawn.py", line 154, in find_executable
    path = os.environ['PATH']
  File "/home/henry/code/cpython/Lib/os.py", line 450, in __getitem__
    value = self._data[self.encodekey(key)]
KeyError: b'PATH'

1 test failed:
    test_distutils
[98227 refs]

Maybe it's not really a problem, and having a system without PATH
defined shouldn't be supported because it's too "weird".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12420>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:17:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 14:17:16 +0000
Subject: [issue11493] Add python.exe-gdb.py to .hgignore
In-Reply-To: <1300088302.91.0.551103844028.issue11493@psf.upfronthosting.co.za>
Message-ID: <1309184236.74.0.454101828993.issue11493@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ah, it?s for Mac.  gdb + .exe sounded strange in my head :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11493>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:19:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Jun 2011 14:19:12 +0000
Subject: [issue12417] Inappropriate copyright on profile files
In-Reply-To: <1309159902.95.0.523889608619.issue12417@psf.upfronthosting.co.za>
Message-ID: <E1QbCec-0000mI-FZ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 55219254eb77 by Benjamin Peterson in branch '2.7':
update profile license (closes #12417)
http://hg.python.org/cpython/rev/55219254eb77

New changeset e50963c3119d by Benjamin Peterson in branch '3.2':
update profile license (closes #12417)
http://hg.python.org/cpython/rev/e50963c3119d

New changeset 5ae1711d9c19 by Benjamin Peterson in branch 'default':
merge 3.2 (#12417)
http://hg.python.org/cpython/rev/5ae1711d9c19

----------
nosy: +python-dev
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12417>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:20:07 2011
From: report at bugs.python.org (Henry Precheur)
Date: Mon, 27 Jun 2011 14:20:07 +0000
Subject: [issue12420] distutils crashes if PATH is not defined
In-Reply-To: <20110627141009.GA733@onion.novuscom.net>
Message-ID: <20110627142005.GA4737@onion.novuscom.net>


Henry Precheur <henry at precheur.org> added the comment:

I don't know exactly in which context find_executable should be used,
but after taking a closer look it seems that returning None when PATH is
not defined could "work".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12420>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:21:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 14:21:36 +0000
Subject: [issue12417] Inappropriate copyright on profile files
In-Reply-To: <1309159902.95.0.523889608619.issue12417@psf.upfronthosting.co.za>
Message-ID: <1309184496.71.0.228334057094.issue12417@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great news for Debian users!  Thanks to all involved.

----------
nosy: +eric.araujo
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12417>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:33:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 14:33:09 +0000
Subject: [issue12420] distutils crashes if PATH is not defined
In-Reply-To: <1309177997.74.0.17903211546.issue12420@psf.upfronthosting.co.za>
Message-ID: <1309185189.13.0.716890472446.issue12420@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay, I see the original use case (#12401).  I think the proper thing to do is to skip tests that rely on the environment being non-empty.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12420>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:36:26 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Jun 2011 14:36:26 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1309185386.36.0.311192020613.issue12398@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

But senthil already demonstrated in the previous issue that it does not become a unicode string unless you use unicode input.

You also claimed that your test program here succeeded in python2.6, but it does not.  This casts a little bit of doubt on your claim that there is a regression.

Can you produce a minimal example of using httplib that demonstrates the regression?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12398>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:38:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 14:38:20 +0000
Subject: [issue12296] Minor clarification in devguide
In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>
Message-ID: <1309185500.71.0.602310446193.issue12296@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay for a new sentence.  I think repeating new is clearer:

(This obviously does not apply to new classes or functions, or new optional arguments.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12296>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:38:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 14:38:39 +0000
Subject: [issue12169] Factor out common code for d2 commands register,
	upload and upload_docs
In-Reply-To: <1306255725.22.0.23750798807.issue12169@psf.upfronthosting.co.za>
Message-ID: <1309185519.91.0.555176105637.issue12169@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22309/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12169>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:38:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 14:38:42 +0000
Subject: [issue12169] Factor out common code for d2 commands register,
	upload and upload_docs
In-Reply-To: <1306255725.22.0.23750798807.issue12169@psf.upfronthosting.co.za>
Message-ID: <1309185522.45.0.883706974497.issue12169@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22330/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12169>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:40:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Jun 2011 14:40:49 +0000
Subject: [issue12419] Add ident parameter to SysLogHandler
In-Reply-To: <1309177677.59.0.756868126424.issue12419@psf.upfronthosting.co.za>
Message-ID: <E1QbCzX-0003Q8-OU@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6baa90fa2b6d by Vinay Sajip in branch 'default':
Closes #12419: Added ident to SysLogHandler.
http://hg.python.org/cpython/rev/6baa90fa2b6d

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12419>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:41:13 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 27 Jun 2011 14:41:13 +0000
Subject: [issue11302] Add more tests to test_ast.py
In-Reply-To: <1298496457.65.0.147228634144.issue11302@psf.upfronthosting.co.za>
Message-ID: <1309185673.73.0.989408026259.issue11302@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

You still haven't explained why including multiline literals is a good idea.

Also, the reason we avoid matching exact messages is it can vary across implementations. You can still do an accurate test with something like self.assertIn("foobar", str(e))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11302>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:41:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 14:41:25 +0000
Subject: [issue12169] Factor out common code for d2 commands register,
	upload and upload_docs
In-Reply-To: <1306255725.22.0.23750798807.issue12169@psf.upfronthosting.co.za>
Message-ID: <1309185685.86.0.777213968657.issue12169@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great patch, thanks!  It?s on the top of my commit list.

----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12169>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:42:10 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 27 Jun 2011 14:42:10 +0000
Subject: [issue12419] Add ident parameter to SysLogHandler
In-Reply-To: <1309177677.59.0.756868126424.issue12419@psf.upfronthosting.co.za>
Message-ID: <1309185730.58.0.125621049868.issue12419@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

N.B. I did not add an additional constructor arg - instead, it's a class-level attribute which can be overridden at class or instance level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12419>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:44:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 14:44:30 +0000
Subject: [issue10020] docs for sqlite3 describe functions not available
	without recompiling
In-Reply-To: <1286124753.24.0.309036392806.issue10020@psf.upfronthosting.co.za>
Message-ID: <1309185870.12.0.314978112514.issue10020@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I just noticed that the blocks in reST should use three-space indent, not two.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10020>
_______________________________________

From report at bugs.python.org  Mon Jun 27 16:50:15 2011
From: report at bugs.python.org (Floris Bruynooghe)
Date: Mon, 27 Jun 2011 14:50:15 +0000
Subject: [issue12419] Add ident parameter to SysLogHandler
In-Reply-To: <1309177677.59.0.756868126424.issue12419@psf.upfronthosting.co.za>
Message-ID: <1309186215.89.0.474799768081.issue12419@psf.upfronthosting.co.za>


Floris Bruynooghe <floris.bruynooghe at gmail.com> added the comment:

That was quick, thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12419>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:00:51 2011
From: report at bugs.python.org (Sven Marnach)
Date: Mon, 27 Jun 2011 15:00:51 +0000
Subject: [issue4296] Python assumes identity implies equivalence;
	contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1309186851.9.0.389222293539.issue4296@psf.upfronthosting.co.za>


Sven Marnach <sven at marnach.net> added the comment:

The behaviour discussed in this thread does not seem to be reflected in Python's documentation.  The documentation of __eq__() [1] doesn't mention that objects should compare equal to themselves.

 [1]: http://docs.python.org/dev/reference/datamodel.html#object.__eq__

There are several places in the documentation that are wrong for NaNs; just one example is the documentation of sequence types [2], which states:

> This means that to compare equal, every element must compare equal
> and the two sequences must be of the same type and have the same
> length.

 [2]: http://docs.python.org/dev/library/stdtypes.html#sequence-types-str-bytes-bytearray-list-tuple-range

It's probably not worthwhile to "fix" all the places in the documentation that implicitly assume that objects compare equal to themselves, but it probably is a good idea to mention that __eq__() implementations should fulfil this assumption to avoid strange behaviour when used in combination with standard containers.  Any thoughts?

----------
nosy: +smarnach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:06:11 2011
From: report at bugs.python.org (Vincent Legoll)
Date: Mon, 27 Jun 2011 15:06:11 +0000
Subject: [issue11302] Add more tests to test_ast.py
In-Reply-To: <1298496457.65.0.147228634144.issue11302@psf.upfronthosting.co.za>
Message-ID: <1309187171.86.0.0602872471233.issue11302@psf.upfronthosting.co.za>


Vincent Legoll <vincent.legoll at gmail.com> added the comment:

I was testing exact matches on the strings because I think pypy wants to be as compliant as possible with cpython, and IMHO that include exception msgs as far as possible. I don't see any reason to be different just for the sake of it.

As a user I'd find strange not to get same exc msgs from different implementations, and it'll make me loose some time digging why those difference exist...

Back to the patch:

The multiline (and also differing offsets) are there for testing .lineno & .col_offset AST node's attributes. (there was a bug in pypy's implementation of those back then...)

Do you want that explained in the comment ?

Do you want me to add "self.assertIn("foobar", str(e))" in the tests, remove the comments or let them as in the patch #2 ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11302>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:08:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 15:08:45 +0000
Subject: [issue11302] Add more tests to test_ast.py
In-Reply-To: <1298496457.65.0.147228634144.issue11302@psf.upfronthosting.co.za>
Message-ID: <1309187325.19.0.329895398063.issue11302@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I think pypy wants to be as compliant as possible with cpython, and
> IMHO that include exception msgs as far as possible. I don't see any
> reason to be different just for the sake of it.
>
> As a user I'd find strange not to get same exc msgs from different
> implementations, and it'll make me loose some time digging why those
> difference exist...

The language reference purposefully makes no guarantee about the error messages, and in some cases about exception types too (AttributeError vs. TypeError), so your feeling contradict Python?s rules.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11302>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:09:58 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 27 Jun 2011 15:09:58 +0000
Subject: [issue11302] Add more tests to test_ast.py
In-Reply-To: <1309187171.86.0.0602872471233.issue11302@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=WAAzBZ6hym3ufVh_EveroT9CYAA@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/6/27 Vincent Legoll <report at bugs.python.org>:
>
> Vincent Legoll <vincent.legoll at gmail.com> added the comment:
>
> I was testing exact matches on the strings because I think pypy wants to be as compliant as possible with cpython, and IMHO that include exception msgs as far as possible. I don't see any reason to be different just for the sake of it.

It's not difference just for the sake of it. Exact compatibility with
errors messages is not particularly useful as long as they have the
same semantic meaning.

>
> As a user I'd find strange not to get same exc msgs from different implementations, and it'll make me loose some time digging why those difference exist...

The usually mean the same thing; they're just worded differently.

>
> Back to the patch:
>
> The multiline (and also differing offsets) are there for testing .lineno & .col_offset AST node's attributes. (there was a bug in pypy's implementation of those back then...)
>
> Do you want that explained in the comment ?
>
> Do you want me to add "self.assertIn("foobar", str(e))" in the tests, remove the comments or let them as in the patch #2 ?

If you want, you can test the exc message with the assertIn pattern.

I don't find there's much potential for mistaking where the attribute
error is in "x.not_an_attribute". :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11302>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:14:20 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 27 Jun 2011 15:14:20 +0000
Subject: [issue12416] packaging does not have hooks callable during
	distribution removal
In-Reply-To: <1309132247.11.0.698244418605.issue12416@psf.upfronthosting.co.za>
Message-ID: <1309187660.46.0.433536420377.issue12416@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Sounds good. Also, we should make the assumption that this hook might be deactivated or might fail. So it should not break the uninstallation in this case (a warning seem fine)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12416>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:16:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 15:16:06 +0000
Subject: [issue12416] packaging does not have hooks callable during
	distribution removal
In-Reply-To: <1309132247.11.0.698244418605.issue12416@psf.upfronthosting.co.za>
Message-ID: <1309187766.33.0.762014255795.issue12416@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Definitely, hooks do not stop operation.  I?ll double-check that.  We may want an option to turn hooks failures into fatal errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12416>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:17:58 2011
From: report at bugs.python.org (Henry Precheur)
Date: Mon, 27 Jun 2011 15:17:58 +0000
Subject: [issue12420] distutils crashes if PATH is not defined
In-Reply-To: <1309185189.13.0.716890472446.issue12420@psf.upfronthosting.co.za>
Message-ID: <20110627151756.GA20626@onion.novuscom.net>


Henry Precheur <henry at precheur.org> added the comment:

I think that returning None would be a better option. The function
documentation says:

  Tries to find 'executable' in the directories listed in 'path'.

  A string listing directories separated by 'os.pathsep'; defaults to
  os.environ['PATH'].  Returns the complete filename or None if not found.

If os.environ['PATH'] is empty the function returns None:

  >>> from distutils.spawn import find_executable
  >>> find_executable('does not exist', path='/bin:/usr/bin') is None
  True
  >>> find_executable('test', path='') is None
  True

This would be consistent with the function definition. If PATH is
undefined, the executable cannot be found, therefor returning None seems
like the right thing to do.

On Mon, Jun 27, 2011 at 02:33:09PM +0000, ??ric Araujo wrote:
> 
> ??ric Araujo <merwok at netwok.org> added the comment:
> 
> Okay, I see the original use case (#12401).  I think the proper thing to do is to skip tests that rely on the environment being non-empty.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12420>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12420>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:19:00 2011
From: report at bugs.python.org (Henry Precheur)
Date: Mon, 27 Jun 2011 15:19:00 +0000
Subject: [issue12420] distutils tests fail if PATH is not defined
In-Reply-To: <1309177997.74.0.17903211546.issue12420@psf.upfronthosting.co.za>
Message-ID: <1309187940.1.0.890810255488.issue12420@psf.upfronthosting.co.za>


Changes by Henry Precheur <henry at precheur.org>:


----------
title: distutils crashes if PATH is not defined -> distutils tests fail if PATH is not defined

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12420>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:21:41 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 27 Jun 2011 15:21:41 +0000
Subject: [issue12416] packaging does not have hooks callable during
	distribution removal
In-Reply-To: <1309132247.11.0.698244418605.issue12416@psf.upfronthosting.co.za>
Message-ID: <1309188101.68.0.296214175859.issue12416@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

We need to make it crystal clear in the doc: developers need to understand this behavior.

Also, for a fatal error, I am -1 for activating this for an uninstall hook because we want to uninstall wathever happens in the hooks, +1 for others (as long as it's coupled with a --force option)

It can be a specific exception the hook can raise to stop the process

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12416>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:27:21 2011
From: report at bugs.python.org (Vincent Legoll)
Date: Mon, 27 Jun 2011 15:27:21 +0000
Subject: [issue11302] Add more tests to test_ast.py
In-Reply-To: <1298496457.65.0.147228634144.issue11302@psf.upfronthosting.co.za>
Message-ID: <1309188441.22.0.881574376267.issue11302@psf.upfronthosting.co.za>


Vincent Legoll <vincent.legoll at gmail.com> added the comment:

* removed the comments for exc msgs
* added explanation to multiline statements
* added 2 tests to test_AST_objects()

Regarding ?ric's comment, I'm starting to wonder if those Exception tests should be added to cpython's testsuite. Maybe that would only be beneficial for pypy...

----------
Added file: http://bugs.python.org/file22496/add-more-tests-for-ast_py-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11302>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:29:45 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 27 Jun 2011 15:29:45 +0000
Subject: [issue12422] When deepcopying,
	don't store immutable objects in the memo dict
In-Reply-To: <1309188584.96.0.531711570592.issue12422@psf.upfronthosting.co.za>
Message-ID: <1309188584.96.0.531711570592.issue12422@psf.upfronthosting.co.za>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

All storing immutable objects in the memo dict does is slow stuff down, due to having a larger hash table, and on some other Python's causing hilarious levels of GC pressure.  Using http://paste.pocoo.org/show/421310/ as a benchmark, CPython get's a 2x speedup on the deepcopy portion, and PyPy a 20x.  Patch is attached.

----------
components: Library (Lib)
files: d.diff
keywords: patch
messages: 139300
nosy: alex
priority: normal
severity: normal
status: open
title: When deepcopying, don't store immutable objects in the memo dict
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file22497/d.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12422>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:30:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 15:30:37 +0000
Subject: [issue12420] distutils tests fail if PATH is not defined
In-Reply-To: <1309177997.74.0.17903211546.issue12420@psf.upfronthosting.co.za>
Message-ID: <1309188637.88.0.802023166056.issue12420@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

To explain my position: distutils is a very brittle codebase that?s used and monkey-patched by a lot of third-party code.  In the past, before the forking of distutils/packaging, Tarek tried to gradually improve distutils but he got a lot of pushback when his changes broke this third-party code that relied on known bugs or undocumented behavior or worked around it.  That?s why a feature freeze is now in effect, and behavior is not changed unless it is to fix a bug.

In this case, it is not documented that distutils should run under python -E, and nobody reported it as a bug before, that?s why I have the position that the tests that require $PATH should be skipped, and the code left untouched.

For distutils2 (named packaging in the 3.3 standard library), we can improve find_executable.  We even want to extract it and move it to shutil: #444582

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12420>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:34:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 15:34:41 +0000
Subject: [issue12416] packaging does not have hooks callable during
	distribution removal
In-Reply-To: <1309132247.11.0.698244418605.issue12416@psf.upfronthosting.co.za>
Message-ID: <1309188881.06.0.825323086791.issue12416@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The setup.cfg spec says only this:

> The callables are executed in the order they?re found in the file; if
> one of them cannot be found, tools should not stop, but for example
> produce a warning and continue with the next line.

packaging/commandhooks does not say anything.  I?ll open a bug to add docs and tests about that, and a feature request for the new option to turn warnings into fatal errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12416>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:41:09 2011
From: report at bugs.python.org (Carl Friedrich Bolz)
Date: Mon, 27 Jun 2011 15:41:09 +0000
Subject: [issue12422] When deepcopying,
	don't store immutable objects in the memo dict
In-Reply-To: <1309188584.96.0.531711570592.issue12422@psf.upfronthosting.co.za>
Message-ID: <1309189269.96.0.157541197516.issue12422@psf.upfronthosting.co.za>


Changes by Carl Friedrich Bolz <cfbolz at gmx.de>:


----------
nosy: +Carl.Friedrich.Bolz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12422>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:44:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 15:44:30 +0000
Subject: [issue8617] Better document user site-packages in site module doc
In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>
Message-ID: <1309189470.9.0.0819793188958.issue8617@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22498/pep370-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8617>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:45:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 15:45:08 +0000
Subject: [issue8617] Better document user site-packages in site module doc
In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>
Message-ID: <1309189508.17.0.568939942995.issue8617@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +needs review
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8617>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:50:24 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 27 Jun 2011 15:50:24 +0000
Subject: [issue12422] When deepcopying,
	don't store immutable objects in the memo dict
In-Reply-To: <1309188584.96.0.531711570592.issue12422@psf.upfronthosting.co.za>
Message-ID: <1309189824.32.0.919623883195.issue12422@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

A slightly cleverer version (or less clever, depending on how you approach the issue) that also works with tuples of immutable content.

----------
Added file: http://bugs.python.org/file22499/d.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12422>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:54:01 2011
From: report at bugs.python.org (sorin)
Date: Mon, 27 Jun 2011 15:54:01 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1309190041.09.0.909953424896.issue12398@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

I updated the gist and made a minimal test
https://gist.github.com/1047551

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12398>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:54:46 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 27 Jun 2011 15:54:46 +0000
Subject: [issue10020] docs for sqlite3 describe functions not available
	without recompiling
In-Reply-To: <1286124753.24.0.309036392806.issue10020@psf.upfronthosting.co.za>
Message-ID: <1309190086.87.0.763631164349.issue10020@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Eric, you mean for the whole of sqlite3 docmentation or the part in the footnote?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10020>
_______________________________________

From report at bugs.python.org  Mon Jun 27 17:58:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 15:58:32 +0000
Subject: [issue10020] docs for sqlite3 describe functions not available
	without recompiling
In-Reply-To: <1286124753.24.0.309036392806.issue10020@psf.upfronthosting.co.za>
Message-ID: <1309190312.72.0.0963947939619.issue10020@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I mean in the two commits.  I can check the whole file later (and also use automatic reST footnotes, [#] instead of [#fn1]).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10020>
_______________________________________

From report at bugs.python.org  Mon Jun 27 18:03:36 2011
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 27 Jun 2011 16:03:36 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1309122286.48.0.450479646042.issue5999@psf.upfronthosting.co.za>
Message-ID: <17D31D0C-30C1-4715-AC14-E1E432710010@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On 2011-06-26, at 2:04 PM, Terry J. Reedy wrote:

> Terry J. Reedy <tjreedy at udel.edu> added the comment:
> 
> Sridhar, is there still a problem with current 3.2/3?
> 
> If you are no longer working on this, I think we should close as languishing/postponed.

I am not working on this yet (its low prio), but will try building 3.2 on HP-UX once 3.2 final is released.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Mon Jun 27 18:07:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Jun 2011 16:07:26 +0000
Subject: [issue12385] the help for bytearray.maketrans describes
	bytes.maketrans
In-Reply-To: <1308699300.81.0.100519829981.issue12385@psf.upfronthosting.co.za>
Message-ID: <E1QbELN-0003Y7-2p@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 586745894ab8 by Senthil Kumaran in branch '3.2':
Fix closes Issue12385 - Clarify maketrans method docstring for bytes and bytearray object.
http://hg.python.org/cpython/rev/586745894ab8

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12385>
_______________________________________

From report at bugs.python.org  Mon Jun 27 18:11:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 16:11:10 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1309191070.98.0.629078490863.issue5999@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

??Python 3.2 was released on February 20th, 2011.?? (from python.org)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Mon Jun 27 18:22:06 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 27 Jun 2011 16:22:06 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1309191726.4.0.488266856761.issue12043@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12043>
_______________________________________

From report at bugs.python.org  Mon Jun 27 18:23:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 16:23:09 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1309191789.34.0.586083527697.issue12043@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you add links, a list of problems, dependency bugs or a patch?  Otherwise this is an empty placeholder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12043>
_______________________________________

From report at bugs.python.org  Mon Jun 27 18:27:15 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 27 Jun 2011 16:27:15 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1309192035.28.0.796651128512.issue12043@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I'm starting to work on a patch right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12043>
_______________________________________

From report at bugs.python.org  Mon Jun 27 18:28:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Jun 2011 16:28:37 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1309192117.55.0.126760166134.issue10403@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Alexander, could you comment on the review page about datetime.rst changes?

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Mon Jun 27 18:39:48 2011
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 27 Jun 2011 16:39:48 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1309191070.98.0.629078490863.issue5999@psf.upfronthosting.co.za>
Message-ID: <AB2907A2-94BC-457A-BDF1-D304BD2ABEEA@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On 2011-06-27, at 9:11 AM, ?ric Araujo wrote:

> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> ? Python 3.2 was released on February 20th, 2011. ? (from python.org)

My mistake; I meant to say 3.2.1 final.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Mon Jun 27 18:47:36 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 27 Jun 2011 16:47:36 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1309174093.79.0.141565096932.issue10181@psf.upfronthosting.co.za>
Message-ID: <20110627164535.GA24966@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Pauli Virtanen <report at bugs.python.org> wrote:
> skrah writes:
> > For example, an exporting object could provide a sliced view by adding 
> > a getslicedbufferproc to PyBufferProcs:
> >
> > int PyObject_GetSlicedBuffer(PyObject *obj, Py_buffer *view, 
> >                              int flags, PyObject *key);
> 
> The same thing can be done via
> 
>     PyObject_GetBuffer(obj, &view, flags);
>     PyBuffer_Slice(&view, &sliced_view, flags, key);
> 
> given an implementation of PyBuffer_Slice. The logic in PyBuffer_Slice does
> not depend on where the buffer comes from, and every buffer can be sliced.

Ok, that sounds good. I came across a comment that base objects can change
their memory layout:

http://mail.python.org/pipermail/python-dev/2007-April/072606.html

Is that something that must be taken care of?

> >  o The invariant that all allocated memory in the buffer belongs
> >    to the exporting object remains intact.
> 
> Numpy arrays do not have this invariant, and they happily re-export memory
> owned by someone else.

I'm not sure if we use the same terminology. By "exporting object" I meant
the original base object and this is the invariant I wanted:

   m1 = memoryview(base) # directly from base
   m2 = memoryview(m1)   # redirects getbuffer/releasebuffer to base
   m3 = memoryview(m2)   # redirects getbuffer/releasebuffer to base
   s1 = m3[1::2, 1::2]   # redirects getslicedbuffer/releasebuffer to base

That's also what you mean by "re-exporting", right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Jun 27 19:05:06 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 27 Jun 2011 17:05:06 +0000
Subject: [issue12422] When deepcopying,
	don't store immutable objects in the memo dict
In-Reply-To: <1309188584.96.0.531711570592.issue12422@psf.upfronthosting.co.za>
Message-ID: <1309194306.58.0.0776334463492.issue12422@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

Switched to using assertIs, as merwok suggested.

----------
Added file: http://bugs.python.org/file22500/d.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12422>
_______________________________________

From report at bugs.python.org  Mon Jun 27 19:17:07 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 27 Jun 2011 17:17:07 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1309180676.88.0.541176207355.issue10181@psf.upfronthosting.co.za>
Message-ID: <20110627171506.GA26001@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Nick Coghlan <report at bugs.python.org> wrote:
[Snip liberally]
> The lifecycle problem is unrelated to the details of the buffer *contents*
  though - it's entirely about the fact that clients can't safely copy all
  those pointers (as some may refer to addresses inside the struct) and asking
  the original object for a fresh copy is permitted to return a different answer
  each time.

> The actual *slicing* code in memoryview isn't too bad

I promise that I'll keep quiet about the getslicedbufferproc from now on, since 
there isn't much enthusiasm. :)

The reason I kept mentioning it was that I thought it would eliminate the
need to copy anything at all. All buffers would come from a single, memory
owning base object.

> Does all that make my perspective any clearer?

Yes, thank you. The tricky part is to understand why always redirecting
getbuffer/releasebuffer to the underlying *original base object* is not
sufficient, but as I understood Pauli's last posting that is due to the
addition of the release() method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Jun 27 19:21:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Jun 2011 17:21:59 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1309180676.88.0.541176207355.issue10181@psf.upfronthosting.co.za>
Message-ID: <20110627192156.5a45af20@msiwind>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le Mon, 27 Jun 2011 13:17:57 +0000,
Nick Coghlan <report at bugs.python.org> a ?crit :
> 
> The TL;DR version of the above is that I would like to see it become:
> 
> typedef struct {
>     PyObject_HEAD
>     PyManagedBuffer source_data; // shared read-only Py_buffer access
>     Py_buffer view;  // shape, strides, etc potentially modified
> } PyMemoryViewObject;

Looks ok to me.
(well, acceptable anyway)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Jun 27 19:27:34 2011
From: report at bugs.python.org (Henry Precheur)
Date: Mon, 27 Jun 2011 17:27:34 +0000
Subject: [issue12420] distutils tests fail if PATH is not defined
In-Reply-To: <1309177997.74.0.17903211546.issue12420@psf.upfronthosting.co.za>
Message-ID: <1309195654.12.0.937775474562.issue12420@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

OK it makes sense.

I'm working on fixing the tests. I'm not done yet, but I've attached a patch with my work in progress (some tests still fail). Do you have any comments?

I'll post a complete version later today or tomorrow.

----------
Added file: http://bugs.python.org/file22501/fix_distutils_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12420>
_______________________________________

From report at bugs.python.org  Mon Jun 27 19:48:58 2011
From: report at bugs.python.org (Kamil Kisiel)
Date: Mon, 27 Jun 2011 17:48:58 +0000
Subject: [issue12423] signal handler dpes
Message-ID: <1309196938.32.0.378849463972.issue12423@psf.upfronthosting.co.za>


Changes by Kamil Kisiel <kamil at kamilkisiel.net>:


----------
nosy: kisielk
priority: normal
severity: normal
status: open
title: signal handler dpes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12423>
_______________________________________

From report at bugs.python.org  Mon Jun 27 19:52:10 2011
From: report at bugs.python.org (Kamil Kisiel)
Date: Mon, 27 Jun 2011 17:52:10 +0000
Subject: [issue12423] signal handler doesn't handle SIGABRT from os.abort
In-Reply-To: <1309197130.0.0.320444785748.issue12423@psf.upfronthosting.co.za>
Message-ID: <1309197130.0.0.320444785748.issue12423@psf.upfronthosting.co.za>


New submission from Kamil Kisiel <kamil at kamilkisiel.net>:

It seems that registering a signal handler for SIGABRT doesn't handle the signal from os.abort().

Example code:

import signal, os
import time

def handler(signum, frame):
    print "Signal!"
    raise Exception()

signal.signal(signal.SIGABRT, handler)
os.abort()

The result is the process still core dumps instead of raising an exception. If instead of os.abort I call time.sleep(10) and then send a kill -ABRT from a shell, the exception is raised as expected.

I tried this with Python 2.6 on Gentoo, 2.7 on FC 14, and 2.6 on OS X 10.6.7 with the same result.

Based on the documentation for os.abort, I would expect this to work:

Generate a SIGABRT signal to the current process. On Unix, the default behavior is to produce a core dump; on Windows, the process immediately returns an exit code of 3. Be aware that programs which use signal.signal() to register a handler for SIGABRT will behave differently.

----------
title: signal handler dpes -> signal handler doesn't handle SIGABRT from os.abort
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12423>
_______________________________________

From report at bugs.python.org  Mon Jun 27 20:14:37 2011
From: report at bugs.python.org (Lenard Lindstrom)
Date: Mon, 27 Jun 2011 18:14:37 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1309180676.88.0.541176207355.issue10181@psf.upfronthosting.co.za>
Message-ID: <4E08C885.1020209@telus.net>


Lenard Lindstrom <len-l at telus.net> added the comment:

Using Python reference counting and the garbage collector to control 
when PyBuffer_Release is called has problems. First, it assumes the 
CPython interpreter will always use reference counting. Second, 
PyBuffer_Release may never get called if circular references exist. 
Third, an exception could keep a memoryview object alive in a traceback, 
delaying the PyBuffer_Release call. Finally, it does not play well with 
the memoryview __enter__, __exit__, and release methods. It makes Python 
level context management pointless; instead, just del the memoryview 
instance and hope the garbage collector cooperates. For the old buffer 
protocol and the Numpy array interface, resources have to be released in 
an object's destructor at garbage collection time. There is no other 
choice. If that also becomes the case for the new buffer protocol, then 
there is little incentive to migrate to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Jun 27 20:17:51 2011
From: report at bugs.python.org (Dimitri Tcaciuc)
Date: Mon, 27 Jun 2011 18:17:51 +0000
Subject: [issue12423] signal handler doesn't handle SIGABRT from os.abort
In-Reply-To: <1309197130.0.0.320444785748.issue12423@psf.upfronthosting.co.za>
Message-ID: <1309198671.32.0.943477490175.issue12423@psf.upfronthosting.co.za>


Changes by Dimitri Tcaciuc <dtcaciuc at gmail.com>:


----------
nosy: +dtcaciuc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12423>
_______________________________________

From report at bugs.python.org  Mon Jun 27 20:31:54 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 27 Jun 2011 18:31:54 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <4E0724D2.3080506@v.loewis.de>
Message-ID: <BANLkTinZWPdoUg7nzSekGZXjKkvrB8zd8Q@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Jun 26, 2011 at 8:23 AM, Martin v. L?wis <report at bugs.python.org> wrote:
..
>> I understand that it is an issue of the datetime module. Can it be
>> solved, or is there a design issue in the module?
>
> It's an inherent flaw of broken-down time. Don't use that
> representation;

Not quite.  This is an inherent flaw of expressing time in time zones
with DST adjustments.  Yet even if there was no DST, using local time
for file timestamps is inconvenient because you cannot easily compare
timestamps across systems.  This is similar to using locale encoding
instead of Unicode.  However this flaw does not affect timestamps
expressed in UTC.  UTC is sort of Unicode (or maybe UTF-8) of
timezones.

> the only true representation of point-in-time
> is "seconds since the epoch, as a real number" (IMO, of course).

Mathematically speaking, broken down UTC timestamp is equivalent to
"seconds since the epoch, as a real number".  There are relatively
simple mathematical formulas (defined by POSIX) that convert from one
representation to the other and back.  As long as "real number" and
broken down structure contain the sub-second data to the same
precision, the two representations are mathematically equivalent.  In
practice one representation may be more convenient than the other.
(This is somewhat similar to decimal vs. binary representation of real
numbers.) When performance is an issue "real numbers" may be more
optimal than broken down structures, but in most applications
datetime/timedelta objects are easier to deal with than abstract
numbers.

> Broken-down time has the advantage of being more easily human-readable,
> but is (often deliberately) incomplete (with the notion of partial
> time stamps) and text representations are difficult to parse.
>

I am not sure I understand this.  ISO timestamps are not more
difficult to parse than decimal numbers.  I don't think Python
supports partial timestamps and certainly partial timestamps would not
be appropriate for representing os.stat() fields.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Mon Jun 27 20:34:52 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 27 Jun 2011 18:34:52 +0000
Subject: [issue12422] When deepcopying,
	don't store immutable objects in the memo dict
In-Reply-To: <1309188584.96.0.531711570592.issue12422@psf.upfronthosting.co.za>
Message-ID: <1309199692.5.0.142286089041.issue12422@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

Amaury points out: this is not strictly about immutable objects, but rather objects who's deepcopy is themselves (identity-wise), in some (rare I think) cases this could provide a slowdown.  Specifically a case of [(1, 2, 3)] * 10000 would be slower, because it would review each tuple individually, rather than using the memo'd instance.  I suspect this case is not so common (to have the same identity object, who's deepcopy is itself such as a tuple or object with custom __deepcopy__, many times in a deepcopy object graph), but I have no proof of this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12422>
_______________________________________

From report at bugs.python.org  Mon Jun 27 20:36:27 2011
From: report at bugs.python.org (Pauli Virtanen)
Date: Mon, 27 Jun 2011 18:36:27 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1309199787.8.0.808617443659.issue10181@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

Lenard Lindstrom writes:
> Using Python reference counting and the garbage collector to control 
> when PyBuffer_Release is called has problems.

That's not what's being suggested. The refcounting discussed here is an implementation detail internal to memoryview, and does not affect the possibility to implement `release()` and context management reliably.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Jun 27 20:47:40 2011
From: report at bugs.python.org (Ben Ranker)
Date: Mon, 27 Jun 2011 18:47:40 +0000
Subject: [issue12376] unittest.TextTestResult.__init__ does not pass on its
	init arguments in super call
In-Reply-To: <1308591554.84.0.206840920137.issue12376@psf.upfronthosting.co.za>
Message-ID: <1309200460.67.0.172963224638.issue12376@psf.upfronthosting.co.za>


Ben Ranker <branker at emory.edu> added the comment:

Sorry for any confusion caused by my imprecise use of the word "explodes."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12376>
_______________________________________

From report at bugs.python.org  Mon Jun 27 22:04:00 2011
From: report at bugs.python.org (Lenard Lindstrom)
Date: Mon, 27 Jun 2011 20:04:00 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1309199787.8.0.808617443659.issue10181@psf.upfronthosting.co.za>
Message-ID: <4E08E22C.50404@telus.net>


Lenard Lindstrom <len-l at telus.net> added the comment:

It would if the proposed PyManagedBuffer only releases the Py_buffer 
struct - calls PyBuffer_Release - when its Python reference count goes 
to zero. So a separate reference count will be maintained instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Jun 27 23:05:52 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 27 Jun 2011 21:05:52 +0000
Subject: [issue1475523] gettext breaks on plural-forms header
Message-ID: <1309208752.45.0.466034044518.issue1475523@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ok. This is a different issue, then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1475523>
_______________________________________

From report at bugs.python.org  Mon Jun 27 23:22:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Jun 2011 21:22:58 +0000
Subject: [issue12422] When deepcopying,
	don't store immutable objects in the memo dict
In-Reply-To: <1309188584.96.0.531711570592.issue12422@psf.upfronthosting.co.za>
Message-ID: <E1QbJGi-0008O4-SI@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e24ad85e9608 by Benjamin Peterson in branch 'default':
don't memoize objects that are their own copies (closes #12422)
http://hg.python.org/cpython/rev/e24ad85e9608

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12422>
_______________________________________

From report at bugs.python.org  Mon Jun 27 23:44:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jun 2011 21:44:33 +0000
Subject: [issue12423] signal handler doesn't handle SIGABRT from os.abort
In-Reply-To: <1309197130.0.0.320444785748.issue12423@psf.upfronthosting.co.za>
Message-ID: <1309211073.04.0.987428518693.issue12423@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Extract of abort manual page:

"The  abort()  first  unblocks  the  SIGABRT signal, and then raises that signal for the calling process. This results in the abnormal termination of the process unless the SIGABRT signal is caught and the signal handler does not return (see longjmp(3))."

If you use a Python signal handler, you have to know that the signal is first handled in C. The Python callback is called "later". In your example, the C signal handler is called, but it *returns* and so the process is stopped.

Python exceptions are not implemented using longjmp() but using a global variable (storing the exception object) and functions return NULL, so I don't think that you can handle the abort() in Python.

> If instead of os.abort I call time.sleep(10)
> and then send a kill -ABRT from a shell, the exception
> is raised as expected.

Yes, this is different from abort() (read again abort() manual page, at least its Linux manpage).

--

abort() is really a corner case of signal handling. You have better to avoid abort() in your application, instead of trying to handle it. By the way, what do you want to do on abort()?

If you enable faulthandler, you get the Python traceback on abort().

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12423>
_______________________________________

From report at bugs.python.org  Tue Jun 28 00:28:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jun 2011 22:28:02 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1309213682.91.0.893412289291.issue12352@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

heap_gc_deadlock_lockless.diff: _free_pending_blocks() and free() execute the following instructions in a different order, is it a problem?

+            self._free(block)
+            self._allocated_blocks.remove(block)

vs

+                self._allocated_blocks.remove(block)
+                self._free(block)

You may call _free_pending_blocks() just after loack.acquire() and a second time before before lock.release()... it is maybe overkill, but it should reduce the probability of the delayed free problem.

You may document that _pending_free_blocks.append() and _pending_free_blocks.pop() are atomic in CPython and don't need a specific lock.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Tue Jun 28 00:32:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jun 2011 22:32:34 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1309213954.2.0.961337462486.issue12352@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> You may document that _pending_free_blocks.append()
> and _pending_free_blocks.pop() are atomic in CPython
> and don't need a specific lock.

Oops, i skipped complelty your long comment explaining everything! It is enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Tue Jun 28 00:51:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Jun 2011 22:51:48 +0000
Subject: [issue11302] Add more tests to test_ast.py
In-Reply-To: <1298496457.65.0.147228634144.issue11302@psf.upfronthosting.co.za>
Message-ID: <E1QbKeh-0006vP-HE@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3143cadb2f2d by Benjamin Peterson in branch '2.7':
add more ast tests (closes #11302)
http://hg.python.org/cpython/rev/3143cadb2f2d

New changeset e8d47cbe9b6f by Benjamin Peterson in branch '3.2':
add more ast tests (closes #11302)
http://hg.python.org/cpython/rev/e8d47cbe9b6f

New changeset 323cf9acbccd by Benjamin Peterson in branch 'default':
merge 3.2 (#11302)
http://hg.python.org/cpython/rev/323cf9acbccd

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11302>
_______________________________________

From report at bugs.python.org  Tue Jun 28 00:51:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jun 2011 22:51:49 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1309215109.78.0.596312121915.issue12352@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

There are different technics to workaround this issue. My preferred is heap_gc_deadlock_lockless.diff because it has less border effect and have a well defined behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Tue Jun 28 00:52:11 2011
From: report at bugs.python.org (Nicholas Cole)
Date: Mon, 27 Jun 2011 22:52:11 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1309215131.14.0.361814234986.issue6755@psf.upfronthosting.co.za>


Nicholas Cole <nicholas.cole at gmail.com> added the comment:

Is there any hope that something like this patch will make it into a future version?  As far as I can see, entering accented characters is currently impossible on the latest release versions of python...or am I missing something?

----------
nosy: +Nicholas.Cole

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Tue Jun 28 01:02:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jun 2011 23:02:22 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1309215742.3.0.348250451985.issue6755@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You someone update the patch for Python 3.3? Python 2.7 and 3.2 don't accept new features.

----------
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Tue Jun 28 01:03:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jun 2011 23:03:56 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1309215836.02.0.951587013667.issue6755@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can someone update the patch for Python 3.3? Python 2.7 and 3.2 don't accept new features.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Tue Jun 28 01:04:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jun 2011 23:04:02 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1309215842.95.0.827333553035.issue6755@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
Removed message: http://bugs.python.org/msg139334

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Tue Jun 28 01:12:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jun 2011 23:12:37 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <1309216357.62.0.514916261726.issue12400@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New patch updated according to bitdancer's comment on IRC: only change the -W option. With the patch, -W only runs the test once but captures the output.

The main difference with my patch is that all output is written to stderr, even if the captured output was written into stdout. I don't want to capture stdout and stderr in two differents stream, I prefer to keep the original output order. In case of a failure, the output only concerns a failure.

----------
Added file: http://bugs.python.org/file22502/regrtest_verbose3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Tue Jun 28 01:14:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jun 2011 23:14:11 +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: <1309216451.29.0.214156368517.issue11870@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Your patch is linux3 compliant, go ahead!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11870>
_______________________________________

From report at bugs.python.org  Tue Jun 28 01:16:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jun 2011 23:16:07 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1309216567.04.0.634257794847.issue8912@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/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 28 01:37:42 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Jun 2011 23:37:42 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1309217862.12.0.827666551507.issue12345@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Uh, not until I've seen a lot more evidence that people are habitually writing "TAU = 2 * math.pi" in their programs...

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Tue Jun 28 02:12:46 2011
From: report at bugs.python.org (Eli Collins)
Date: Tue, 28 Jun 2011 00:12:46 +0000
Subject: [issue12424] distutils2: extension section uses bad environment
	marker separator
In-Reply-To: <1309219966.78.0.835295932694.issue12424@psf.upfronthosting.co.za>
Message-ID: <1309219966.78.0.835295932694.issue12424@psf.upfronthosting.co.za>


New submission from Eli Collins <elic at assurancetechnologies.com>:

The _pop_values() function in packaging.config uses "--" as the environment marker separator when parsing extension sections. This doesn't match PEP 345, or how the metadata section is currently parsed, both of which use ";" instead. Also, "--" is frequently found in compiler option strings, which will probably cause conflicts in the future. 

The attached patch changes _pop_values() and related unit tests to use ";" as the separator, as well as tries to clarify some of _pop_values()'s internal comments.

----------
assignee: tarek
components: Distutils2
messages: 139339
nosy: alexis, eli.collins, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils2: extension section uses bad environment marker separator
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12424>
_______________________________________

From report at bugs.python.org  Tue Jun 28 02:16:04 2011
From: report at bugs.python.org (Eli Collins)
Date: Tue, 28 Jun 2011 00:16:04 +0000
Subject: [issue12424] distutils2: extension section uses bad environment
	marker separator
In-Reply-To: <1309219966.78.0.835295932694.issue12424@psf.upfronthosting.co.za>
Message-ID: <1309220164.73.0.136305145044.issue12424@psf.upfronthosting.co.za>


Changes by Eli Collins <elic at assurancetechnologies.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22503/cpython_issue12424.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12424>
_______________________________________

From report at bugs.python.org  Tue Jun 28 02:25:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jun 2011 00:25:53 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>
Message-ID: <1309220753.88.0.301103656267.issue12303@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> test_sigwaitinfo_interrupted() fails because SIGALRM
> signal handler is called ...

Oh, the problem is that sigwait() behaviour changes after a fork: it is interrupted if an unexpected signal is received, but the signal handler is not called. It behaves correctly (the signal handler is called) without the fork.

The correct fix is maybe to avoid the os.fork() instead of skipping the test on FreeBSD 6.

----------
nosy: +neologix
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Tue Jun 28 02:58:25 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 28 Jun 2011 00:58:25 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1309222705.19.0.199391578033.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

memoryview.release() will raise an exception if you call it when the underlying PyManagedBuffer instance has a refcount > 1. So the explicit memory management still works, and if you mess it up by leaving dangling references around you'll run the risk of getting an exception (CPython will mostly cleanly things up for you due to the refcounting, but we're well used to CPython users getting away with that kind of bug and being surprised when they port to a fully garbage collected implementation like PyPy, IronPython or Jython).

It isn't pretty, but it's the most practical way to cope with the lifecycle issues. The other alternative is to obediently force release of the buffer and then throw exceptions on subsequent *access*, the way we do with files. I'm less in favour of that approach, since it results in additional runtime overhead as you have to keep checking the state validity and I think it generates the exception in the wrong place - the exception should be triggered where the implicit assertion that "all other references are gone and this object should be released right now" has been violated, not at some later random location where the object happens to be used. (I'm also swayed by the backwards compatibility argument: we can easily move from "refcount must be 1" enforcement to the laissez-faire approach used by files. You can't go in the other direction without the potential to break working code)

The reason redirecting all requests to the underlying object doesn't work is because repeated calls to getbuffer on mutable objects are allowed to return *different* answers. Assume we have a mutable array type that allows changes while memory is exported by keeping the old buffer around until all references are released. Then we want the following behaviour:

  a = mutable_byte_array(100) # 100 byte array
  m1 = memoryview(a) # View of original 100 byte array
  a.resize(0) # Array is now zero length, but old buffer is still valid
  m2 = m1[:]
  m3 = memoryview(m1)
  # Both m2 and m3 should provide access to the *original* 100 byte
  # array, not to the now empty *current* array
  # Having len(m2) and len(m3) differ from len(m1) because the
  # original source array had changed would be incredibly confusing
  # When m1, m2 and m3 all go away then the original array will be
  # released

The builtin bytearray avoids this issue by simply disallowing mutation while a buffer is exported, but memoryview needs to cope with arbitrary third party objects which may behave like the hypothetical mutable_byte_array().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Tue Jun 28 04:53:36 2011
From: report at bugs.python.org (Henry Precheur)
Date: Tue, 28 Jun 2011 02:53:36 +0000
Subject: [issue12420] distutils tests fail if PATH is not defined
In-Reply-To: <1309177997.74.0.17903211546.issue12420@psf.upfronthosting.co.za>
Message-ID: <1309229616.89.0.471255652151.issue12420@psf.upfronthosting.co.za>


Changes by Henry Precheur <henry at precheur.org>:


Removed file: http://bugs.python.org/file22501/fix_distutils_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12420>
_______________________________________

From report at bugs.python.org  Tue Jun 28 04:57:50 2011
From: report at bugs.python.org (Henry Precheur)
Date: Tue, 28 Jun 2011 02:57:50 +0000
Subject: [issue12420] distutils tests fail if PATH is not defined
In-Reply-To: <1309177997.74.0.17903211546.issue12420@psf.upfronthosting.co.za>
Message-ID: <1309229870.46.0.192281522253.issue12420@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

I've fixed the last failing tests, but I'm unsure it's the right way to do it.

Take a look at the part for Lib/distutils/tests/test_build_ext.py. I just check that os.environ['PATH'] is defined. I'm not 100% certain that this will work on every platforms.

----------
Added file: http://bugs.python.org/file22504/fix_distutils_tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12420>
_______________________________________

From report at bugs.python.org  Tue Jun 28 07:07:12 2011
From: report at bugs.python.org (Paulo Scardine)
Date: Tue, 28 Jun 2011 05:07:12 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1309237632.58.0.0329191643878.issue11281@psf.upfronthosting.co.za>


Paulo Scardine <paulo at scardine.com.br> added the comment:

Is there anything I should improve in order to get this patch commited?

----------
resolution:  -> remind

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Tue Jun 28 08:20:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 28 Jun 2011 06:20:41 +0000
Subject: [issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl
	8.5.9 (Cocoa)
In-Reply-To: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>
Message-ID: <E1QbRf0-0003y9-JP@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 4a0b929b5c3d by Ned Deily in branch '2.7':
Issue #10736: Fix test_ttk test_widgets failures with Cocoa Tk 8.5.9
http://hg.python.org/cpython/rev/4a0b929b5c3d

New changeset 570cdef34066 by Ned Deily in branch '3.2':
Issue #10736: Fix test_ttk test_widgets failures with Cocoa Tk 8.5.9
http://hg.python.org/cpython/rev/570cdef34066

New changeset b7c61000ceec by Ned Deily in branch 'default':
Issue #10736: Fix test_ttk test_widgets failures with Cocoa Tk 8.5.9
http://hg.python.org/cpython/rev/b7c61000ceec

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10736>
_______________________________________

From report at bugs.python.org  Tue Jun 28 08:21:57 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 28 Jun 2011 06:21:57 +0000
Subject: [issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl
	8.5.9 (Cocoa)
In-Reply-To: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>
Message-ID: <1309242117.78.0.0137528030501.issue10736@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10736>
_______________________________________

From report at bugs.python.org  Tue Jun 28 09:13:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 28 Jun 2011 07:13:51 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <E1QbSUY-00083g-0T@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset abfe28e7e5cd by Ned Deily in branch '2.7':
Issue #8746: Correct faulty configure checks so that os.chflags() and
http://hg.python.org/cpython/rev/abfe28e7e5cd

New changeset 529e26aa4fa3 by Ned Deily in branch '3.2':
Issue #8746: Correct faulty configure checks so that os.chflags() and
http://hg.python.org/cpython/rev/529e26aa4fa3

New changeset 9da64c0bdc33 by Ned Deily in branch 'default':
Issue #8746: Correct faulty configure checks so that os.chflags() and
http://hg.python.org/cpython/rev/9da64c0bdc33

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Tue Jun 28 09:24:37 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 28 Jun 2011 07:24:37 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1309245877.03.0.940430976297.issue8746@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the additional tests, Garrett.  I've applied them (modulo a fix).  I've also applied the corrections to configure which should make os.chflags() and os.lchflags() reappear again in BSD and OS X builds where supported.  I've also added and documented two new OS X specific file flags: UF_HIDDEN and UF_COMPRESSED. Applied in default (for 3.3), 3.2 (3.2.1), and 2.7 (2.7.3).

----------
assignee: ronaldoussoren -> ned.deily
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending
type: compile error -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Tue Jun 28 09:38:27 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 28 Jun 2011 07:38:27 +0000
Subject: [issue12425] gettext breaks on empty plural-forms value
In-Reply-To: <1309246707.61.0.397995745183.issue12425@psf.upfronthosting.co.za>
Message-ID: <1309246707.61.0.397995745183.issue12425@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

See https://bugzilla.redhat.com/show_bug.cgi?id=692632 for more details and a proposed patch.

----------
components: Library (Lib)
messages: 139347
nosy: djc
priority: normal
severity: normal
status: open
title: gettext breaks on empty plural-forms value
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12425>
_______________________________________

From report at bugs.python.org  Tue Jun 28 09:38:55 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 28 Jun 2011 07:38:55 +0000
Subject: [issue1475523] gettext breaks on plural-forms header
Message-ID: <1309246735.14.0.368265213194.issue1475523@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Okay, I've filed issue12425.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1475523>
_______________________________________

From report at bugs.python.org  Tue Jun 28 09:55:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 28 Jun 2011 07:55:00 +0000
Subject: [issue12141] sysconfig.get_config_vars('srcdir') fails in specific
	cases
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <E1QbT8N-00031s-4I@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c8ffa3891d5e by Ned Deily in branch '2.7':
Issue #12141: Install a copy of template C module file so that
http://hg.python.org/cpython/rev/c8ffa3891d5e

New changeset de226a510b52 by Ned Deily in branch '3.2':
Issue #12141: Install a copy of template C module file so that
http://hg.python.org/cpython/rev/de226a510b52

New changeset ef8e9e99de88 by Ned Deily in branch 'default':
Issue #12141: Install copies of template C module file so that
http://hg.python.org/cpython/rev/ef8e9e99de88

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Tue Jun 28 10:03:07 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 28 Jun 2011 08:03:07 +0000
Subject: [issue12141] sysconfig.get_config_vars('srcdir') fails in specific
	cases
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1309248187.71.0.63519789899.issue12141@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Patches applied as described above for 3.3, 3.2.1, and 2.7.3. I'm setting the status of the issue to pending and, assuming there are no buildbot failures in the near future, I will close it unless anyone sees a reason not to.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Tue Jun 28 10:50:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jun 2011 08:50:03 +0000
Subject: [issue12426] packaging.tests.test_command_install_dist.InstallTestCase
	failure
In-Reply-To: <1309251003.31.0.392399705206.issue12426@psf.upfronthosting.co.za>
Message-ID: <1309251003.31.0.392399705206.issue12426@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

FAIL: test_user_site (packaging.tests.test_command_install_dist.InstallTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/packaging/tests/test_command_install_dist.py", line 93, in test_user_site
    self._test_user_site()
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/packaging/tests/test_command_install_dist.py", line 122, in _test_user_site
    self.assertTrue(os.path.exists(self.user_base))
AssertionError: False is not true

http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/1988/steps/test/logs/stdio

----------
assignee: tarek
components: Distutils2, Tests
messages: 139351
nosy: alexis, eric.araujo, haypo, tarek
priority: normal
severity: normal
status: open
title: packaging.tests.test_command_install_dist.InstallTestCase failure
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12426>
_______________________________________

From report at bugs.python.org  Tue Jun 28 11:14:10 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 28 Jun 2011 09:14:10 +0000
Subject: [issue12427] packaging register fails because "POST data should be
	bytes"
In-Reply-To: <1309252450.32.0.523517261738.issue12427@psf.upfronthosting.co.za>
Message-ID: <1309252450.32.0.523517261738.issue12427@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

vinay at eta-natty:~/projects/nemo$ pysetup3 run register
running register
Registering nemo to http://pypi.python.org/pypi
Traceback (most recent call last):
  File "/usr/local/bin/pysetup3", line 4, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.3/packaging/run.py", line 678, in main
    return dispatcher()
  File "/usr/local/lib/python3.3/packaging/run.py", line 667, in __call__
    return func(self, self.args)
  File "/usr/local/lib/python3.3/packaging/run.py", line 204, in wrapper
    return f(*args, **kwargs)
  File "/usr/local/lib/python3.3/packaging/run.py", line 344, in _run
    dist.run_command(cmd, dispatcher.command_options[cmd])
  File "/usr/local/lib/python3.3/packaging/dist.py", line 761, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python3.3/packaging/command/register.py", line 63, in run
    self.send_metadata()
  File "/usr/local/lib/python3.3/packaging/command/register.py", line 167, in send_metadata
    auth)
  File "/usr/local/lib/python3.3/packaging/command/register.py", line 267, in post_to_server
    result = opener.open(req)
  File "/usr/local/lib/python3.3/urllib/request.py", line 367, in open
    req = meth(req)
  File "/usr/local/lib/python3.3/urllib/request.py", line 1075, in do_request_
    raise TypeError("POST data should be bytes"
TypeError: POST data should be bytes or an iterable of bytes. It cannot be str.
vinay at eta-natty:~/projects/nemo$

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 139352
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: high
severity: normal
status: open
title: packaging register fails because "POST data should be bytes"
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12427>
_______________________________________

From report at bugs.python.org  Tue Jun 28 12:07:18 2011
From: report at bugs.python.org (Brian Thorne)
Date: Tue, 28 Jun 2011 10:07:18 +0000
Subject: [issue12428] functools test coverage
In-Reply-To: <1309255638.21.0.342456839611.issue12428@psf.upfronthosting.co.za>
Message-ID: <1309255638.21.0.342456839611.issue12428@psf.upfronthosting.co.za>


New submission from Brian Thorne <hardbyte at gmail.com>:

The test coverage for functools was down around ~60%, this is a patch to bring that up to ~98%.

Made two changes to the Lib/functools.py file itself:

1) Moved the Python implementation of partial into Lib/functools.py from Lib/test/test_functools.py which gets imported over the same as the Python implementation of cmp_to_key.

2) In order to allow the blocking of _functools, I grouped and moved the import functions from of _functools to the end of the file.

In the test_functools.py file:

3) Added two new tests to TestLRU.

4) Add testing of Python implementation of cmp_to_key. I copied how test_warnings.py tests C and Python implementations of the same function.

5) Made the importing of functools itself far less clear

----------
components: Tests
files: functools.diff
keywords: patch
messages: 139353
nosy: Thorney, ncoghlan, rhettinger
priority: normal
severity: normal
status: open
title: functools test coverage
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22505/functools.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12428>
_______________________________________

From report at bugs.python.org  Tue Jun 28 12:14:41 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 28 Jun 2011 10:14:41 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1308995950.75.0.288905614048.issue12406@psf.upfronthosting.co.za>
Message-ID: <1309256081.6.0.755037852765.issue12406@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> and adding the two files added for packaging should do the trick

Which two files would those be, exactly? In my branch I've changed to logic from parent.physical == "distutils" to parent.physical in ("distutils", "packaging") and this should cover the all the .exes and command_template. I haven't looked at the packaging test stuff, there may need to be some attention directed there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12406>
_______________________________________

From report at bugs.python.org  Tue Jun 28 13:23:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jun 2011 11:23:47 +0000
Subject: [issue12429] test_io.check_interrupted_write() sporadic failures on
	FreeBSD 6 on Python 2.7/3.2
In-Reply-To: <1309260227.84.0.740113314895.issue12429@psf.upfronthosting.co.za>
Message-ID: <1309260227.84.0.740113314895.issue12429@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_io.check_interrupted_write() has two threads and a pipe:

 - reader (thread): read one byte from the pipe
 - writer (main thread): write 1 MB into the pipe

An alarm (SIGALRM) is scheduled in one second. The writer blocks because the pipe buffer is smaller than 1 MB, but it is supposed to fill the pipe. The reader is supposed to exit quickly: the writer wrote a least one byte.

The test fails *sometimes* on FreeBSD 6:

[ 85/352] test_io
Exception in thread Thread-274:
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.2.bolen-freebsd/build/Lib/threading.py", line 736, in _bootstrap_inner
    self.run()
  File "/usr/home/db3l/buildarea/3.2.bolen-freebsd/build/Lib/threading.py", line 689, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/home/db3l/buildarea/3.2.bolen-freebsd/build/Lib/test/test_io.py", line 2660, in _read
    s = os.read(r, 1)
OSError: [Errno 4] Interrupted system call

It is a race condition, this buildbot is very slow. The reader has maybe not enough time to read 1 byte.

The test was fixed in Python 3.3 (#11859) by adding pthread_sigmask() (issue #8407) and using it in the test: commit 28b9702a83d1.

The problem looks to be specific of FreeBSD 6 and 7 (according to #11859). The easiest solution is to skip the test on these platforms.

To workaround the lack of pthread_sigmark(), we can use two processes instead of two threads. But it is maybe too much work just to fix a bug in a test (the bug is not in Python).

----------
components: IO, Tests
messages: 139355
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: test_io.check_interrupted_write() sporadic failures on FreeBSD 6 on Python 2.7/3.2
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12429>
_______________________________________

From report at bugs.python.org  Tue Jun 28 13:38:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jun 2011 11:38:08 +0000
Subject: [issue12429] test_io.check_interrupted_write() sporadic failures on
	FreeBSD 6 on Python 2.7/3.2
In-Reply-To: <1309260227.84.0.740113314895.issue12429@psf.upfronthosting.co.za>
Message-ID: <1309261088.05.0.224944179916.issue12429@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch to skip the test on FreeBSD 5, 6 and 7.

I was unable to reproduce #11859 on my FreeBSD 8 VM, so I didn't add freebsd8.

----------
keywords: +patch
Added file: http://bugs.python.org/file22506/test_io_skip_freebsd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12429>
_______________________________________

From report at bugs.python.org  Tue Jun 28 13:55:03 2011
From: report at bugs.python.org (Seppo Yli-Olli)
Date: Tue, 28 Jun 2011 11:55:03 +0000
Subject: [issue12430] Pip fails to fetch from mirror if PyPi checksum times out
In-Reply-To: <1309262103.36.0.291566083366.issue12430@psf.upfronthosting.co.za>
Message-ID: <1309262103.36.0.291566083366.issue12430@psf.upfronthosting.co.za>


New submission from Seppo Yli-Olli <seppo.yliolli at gmail.com>:

Checksums need to be mirrored as well, otherwise having mirrors is a waste of money because PyPi main server being slow ends up with whole download failing. If this is the wrong bug tracker, please advice me to the right one so this can be resolved.

----------
components: None
files: pip.log
messages: 139357
nosy: Seppo.Yli-Olli
priority: normal
severity: normal
status: open
title: Pip fails to fetch from mirror if PyPi checksum times out
versions: Python 2.7
Added file: http://bugs.python.org/file22507/pip.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12430>
_______________________________________

From report at bugs.python.org  Tue Jun 28 13:56:15 2011
From: report at bugs.python.org (Seppo Yli-Olli)
Date: Tue, 28 Jun 2011 11:56:15 +0000
Subject: [issue12430] Pip fails to fetch from mirror if PyPi checksum times out
In-Reply-To: <1309262103.36.0.291566083366.issue12430@psf.upfronthosting.co.za>
Message-ID: <1309262175.37.0.943470932037.issue12430@psf.upfronthosting.co.za>


Changes by Seppo Yli-Olli <seppo.yliolli at gmail.com>:


----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12430>
_______________________________________

From report at bugs.python.org  Tue Jun 28 14:16:13 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 28 Jun 2011 12:16:13 +0000
Subject: [issue12428] functools test coverage
In-Reply-To: <1309255638.21.0.342456839611.issue12428@psf.upfronthosting.co.za>
Message-ID: <1309263373.72.0.0173524741403.issue12428@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Raymond, do we care whether or not the pure Python version of functools.partial supports inheritance and instance testing?

The constructor is technically documented as returning a "partial object" rather than a simple staticmethod instance with additional attributes.

My own preference leans towards keeping the closure based implementation due to its simplicity, which is what makes it particularly useful as a cross-check on the C implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12428>
_______________________________________

From report at bugs.python.org  Tue Jun 28 14:24:08 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jun 2011 12:24:08 +0000
Subject: [issue12428] functools test coverage
In-Reply-To: <1309255638.21.0.342456839611.issue12428@psf.upfronthosting.co.za>
Message-ID: <1309263848.68.0.490556199853.issue12428@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Raymond, do we care whether or not the 
> pure Python version of functools.partial 
> supports inheritance and instance testing?

We don't care.  The docs make very few
guarantees beyond the core functionality.
Everything else is an implementation detail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12428>
_______________________________________

From report at bugs.python.org  Tue Jun 28 15:32:28 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 28 Jun 2011 13:32:28 +0000
Subject: [issue12430] Pip fails to fetch from mirror if PyPi checksum times out
In-Reply-To: <1309262103.36.0.291566083366.issue12430@psf.upfronthosting.co.za>
Message-ID: <1309267948.31.0.112706706476.issue12430@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Hello,

The PyPI bug tracker is over here (you can find the link on the front
page of http://pypi.python.org/pypi):

http://sourceforge.net/tracker/?group_id=66150&atid=513503


That said, having checksums come from the master server exclusively
seems like a security feature, so I'm not sure whether your suggestion
will be considered.

----------
nosy: +skrah
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12430>
_______________________________________

From report at bugs.python.org  Tue Jun 28 15:37:28 2011
From: report at bugs.python.org (Jon Siddle)
Date: Tue, 28 Jun 2011 13:37:28 +0000
Subject: [issue12431] urllib2.Request.get_full_url() broken in newer versions
	of Python
In-Reply-To: <1309268248.69.0.295956213219.issue12431@psf.upfronthosting.co.za>
Message-ID: <1309268248.69.0.295956213219.issue12431@psf.upfronthosting.co.za>


New submission from Jon Siddle <js at corefiling.co.uk>:

Issue8280 fixed an issue where the fragment was being sent to the server (and returned by get_selector).

Unfortunately the fix means that the "full" URL stored in the Request no longer includes the fragment either.

This is in contradiction to the documentation which states:

 Request.get_full_url()
  Return the URL given in the constructor.

Yet:

 >>> import urllib2
 >>> urllib2.Request("http://host/path#fragment").get_full_url()
 'http://host/path'

The particular use case is a custom scheme handler, which should be able to use the whole of the opaque part of the URL to operate. Ie, our code wants to do something like this:

 urllib2.Request("foo://opaquestring#opaquestring").get_full_url()

----------
messages: 139361
nosy: jonsiddle
priority: normal
severity: normal
status: open
title: urllib2.Request.get_full_url() broken in newer versions of Python
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12431>
_______________________________________

From report at bugs.python.org  Tue Jun 28 15:44:37 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 28 Jun 2011 13:44:37 +0000
Subject: [issue12425] gettext breaks on empty plural-forms value
In-Reply-To: <1309246707.61.0.397995745183.issue12425@psf.upfronthosting.co.za>
Message-ID: <1309268677.39.0.51440461196.issue12425@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/issue12425>
_______________________________________

From report at bugs.python.org  Tue Jun 28 16:38:15 2011
From: report at bugs.python.org (Vincent Legoll)
Date: Tue, 28 Jun 2011 14:38:15 +0000
Subject: [issue12432] remove a bunch of unused imports in Lib
In-Reply-To: <1309271895.63.0.491805316904.issue12432@psf.upfronthosting.co.za>
Message-ID: <1309271895.63.0.491805316904.issue12432@psf.upfronthosting.co.za>


New submission from Vincent Legoll <vincent.legoll at gmail.com>:

Using pylint I found some unused imports in Lib.

I filtered the most obvious ones by hand to produce the attached patch.

Should I submit individual patches, one for each file, so as to ease review ?

----------
components: Library (Lib)
files: unused-imports-2.patch
keywords: patch
messages: 139362
nosy: vincele
priority: normal
severity: normal
status: open
title: remove a bunch of unused imports in Lib
versions: Python 3.4
Added file: http://bugs.python.org/file22508/unused-imports-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12432>
_______________________________________

From report at bugs.python.org  Tue Jun 28 17:25:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 28 Jun 2011 15:25:04 +0000
Subject: [issue12432] remove a bunch of unused imports in Lib
In-Reply-To: <1309271895.63.0.491805316904.issue12432@psf.upfronthosting.co.za>
Message-ID: <E1Qba9v-0001IK-BL@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8c17e898e0e8 by Benjamin Peterson in branch 'default':
remove unused imports (closes #12432)
http://hg.python.org/cpython/rev/8c17e898e0e8

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12432>
_______________________________________

From report at bugs.python.org  Tue Jun 28 17:40:19 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 28 Jun 2011 15:40:19 +0000
Subject: [issue12433] make clean doesn't clean up static libraries on 2.x
In-Reply-To: <1309275619.55.0.00676218612249.issue12433@psf.upfronthosting.co.za>
Message-ID: <1309275619.55.0.00676218612249.issue12433@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

Running 'make clean' leaves libpython*.a behind. The attached patch removes it when make clean is run.

This was resolved on py3k, not trunk; the attached patch matches what was done on py3k.

----------
components: Build
files: cleanup-libpython-dot-a-trunk.patch
keywords: patch
messages: 139364
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: make clean doesn't clean up static libraries on 2.x
type: compile error
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file22509/cleanup-libpython-dot-a-trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12433>
_______________________________________

From report at bugs.python.org  Tue Jun 28 18:04:57 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 28 Jun 2011 16:04:57 +0000
Subject: [issue12433] make clean doesn't clean up static libraries on 2.x
In-Reply-To: <1309275619.55.0.00676218612249.issue12433@psf.upfronthosting.co.za>
Message-ID: <1309277097.24.0.645119915203.issue12433@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

A similar fix was applied and released in both 2.6.6 and 2.7.1.

----------
nosy: +ned.deily
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
type: compile error -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12433>
_______________________________________

From report at bugs.python.org  Tue Jun 28 18:21:21 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 28 Jun 2011 16:21:21 +0000
Subject: [issue12431] urllib2.Request.get_full_url() broken in newer versions
	of Python
In-Reply-To: <1309268248.69.0.295956213219.issue12431@psf.upfronthosting.co.za>
Message-ID: <1309278081.2.0.24697989461.issue12431@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12431>
_______________________________________

From report at bugs.python.org  Tue Jun 28 18:21:27 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 28 Jun 2011 16:21:27 +0000
Subject: [issue12433] make clean doesn't clean up static libraries on 2.x
In-Reply-To: <1309275619.55.0.00676218612249.issue12433@psf.upfronthosting.co.za>
Message-ID: <1309278087.31.0.277841272207.issue12433@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

Is svn not being updated anymore (in lieu of hg)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12433>
_______________________________________

From report at bugs.python.org  Tue Jun 28 18:22:11 2011
From: report at bugs.python.org (Vincent Legoll)
Date: Tue, 28 Jun 2011 16:22:11 +0000
Subject: [issue12432] remove a bunch of unused imports in Lib
In-Reply-To: <1309271895.63.0.491805316904.issue12432@psf.upfronthosting.co.za>
Message-ID: <1309278131.29.0.735345987701.issue12432@psf.upfronthosting.co.za>


Vincent Legoll <vincent.legoll at gmail.com> added the comment:

Looking through http://hg.python.org/cpython/rev/8c17e898e0e8
I see that the glob.py hunk has been applied reversed.

The changeset 68349:55bea11d892e removing it is 3 monthes old...

Looks like I missed a svn->hg migration on my side, sorry for the screwup...

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12432>
_______________________________________

From report at bugs.python.org  Tue Jun 28 18:25:46 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 28 Jun 2011 16:25:46 +0000
Subject: [issue12433] make clean doesn't clean up static libraries on 2.x
In-Reply-To: <1309275619.55.0.00676218612249.issue12433@psf.upfronthosting.co.za>
Message-ID: <1309278346.45.0.194379938057.issue12433@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

No, the svn repos for python itself (at svn.python.org) are frozen as of the hg transition and are for historical reference only.  See http://docs.python.org/devguide/ for more info on current practices.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12433>
_______________________________________

From report at bugs.python.org  Tue Jun 28 18:41:11 2011
From: report at bugs.python.org (Vincent Legoll)
Date: Tue, 28 Jun 2011 16:41:11 +0000
Subject: [issue12432] remove a bunch of unused imports in Lib
In-Reply-To: <1309271895.63.0.491805316904.issue12432@psf.upfronthosting.co.za>
Message-ID: <1309279271.35.0.0090979361604.issue12432@psf.upfronthosting.co.za>


Vincent Legoll <vincent.legoll at gmail.com> added the comment:

This one reverts glob.py to the previous state

----------
Added file: http://bugs.python.org/file22510/reremove-sys-import-from-glob.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12432>
_______________________________________

From report at bugs.python.org  Tue Jun 28 19:27:43 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 28 Jun 2011 17:27:43 +0000
Subject: [issue12431] urllib2.Request.get_full_url() broken in newer versions
	of Python
In-Reply-To: <1309268248.69.0.295956213219.issue12431@psf.upfronthosting.co.za>
Message-ID: <1309282063.94.0.417786581948.issue12431@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

This has been fixed with issue #11703, latest version of Python 2.7 does not exhibit this behaviour anymore:

Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> urllib2.Request('http://host/path#fragment').get_full_url()
'http://host/path#fragment'

----------
components: +Library (Lib)
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12431>
_______________________________________

From report at bugs.python.org  Tue Jun 28 20:38:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Jun 2011 18:38:38 +0000
Subject: [issue12407] test_subinterps fails on Windows
In-Reply-To: <1308999728.78.0.684048233766.issue12407@psf.upfronthosting.co.za>
Message-ID: <1309286318.72.0.741635459297.issue12407@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't really understand why you need this. Under normal setups, the test is already properly skipped under Windows, since there's no rule to build the "Modules/_testembed" with MSVC.
Or are you talking about another kind of setup? Cygwin? mingw?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12407>
_______________________________________

From report at bugs.python.org  Tue Jun 28 20:45:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Jun 2011 18:45:06 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1309286706.17.0.129322185731.issue12352@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Nice work! I also think heap_gc_deadlock_lockless.diff is good, except for Victor's reservation: is it deliberate that you reversed the following two statements in _free_pending_blocks(), compared to the code in free()?

+            self._free(block)
+            self._allocated_blocks.remove(block)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Tue Jun 28 20:47:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Jun 2011 18:47:18 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1309286838.23.0.855181844058.issue12380@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I do agree it is a nuisance that it doesn't work with bytearray instances. After all, these methods are supposed to be homogeneous, and they are when called on a str or bytes object.

----------
assignee: docs at python -> 
stage: committed/rejected -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Tue Jun 28 20:47:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Jun 2011 18:47:34 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1309286854.19.0.24909745461.issue12380@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components:  -Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Tue Jun 28 21:22:58 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 28 Jun 2011 19:22:58 +0000
Subject: [issue12434] Strengthen 2.7 io types warning
In-Reply-To: <1309288978.39.0.732754105333.issue12434@psf.upfronthosting.co.za>
Message-ID: <1309288978.39.0.732754105333.issue12434@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Trying 3.2 code with 2.7, I got this (greatly simplified):

from __future__ import print_function
from io import StringIO
print('hello world', file=StringIO())
Traceback...
TypeError: string argument expected, got 'str'
(StringIO.StringIO works fine, of course.)

This was initially confusing. Suggestion: after

"Note Since this module has been designed primarily for Python 3.x, you have to be aware that all uses of ?bytes? in this document refer to the str type (of which bytes is an alias), and all uses of ?text? refer to the unicode type. "
add
'String' in exception messages may also mean the unicode type."

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 139374
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Strengthen 2.7 io types warning
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12434>
_______________________________________

From report at bugs.python.org  Tue Jun 28 22:39:18 2011
From: report at bugs.python.org (Nicolas Estibals)
Date: Tue, 28 Jun 2011 20:39:18 +0000
Subject: [issue12147] smtplib.send_message does not implement corectly rfc 2822
In-Reply-To: <1306050881.77.0.236550216984.issue12147@psf.upfronthosting.co.za>
Message-ID: <1309293558.07.0.743858306905.issue12147@psf.upfronthosting.co.za>


Nicolas Estibals <nicolas.estibals at gmail.com> added the comment:

Sorry for the late, my week-end was more busy than expected. Here is the corrected version of the patch.

----------
Added file: http://bugs.python.org/file22511/send_message_rfc2822_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12147>
_______________________________________

From report at bugs.python.org  Tue Jun 28 23:00:01 2011
From: report at bugs.python.org (Kamil Kisiel)
Date: Tue, 28 Jun 2011 21:00:01 +0000
Subject: [issue12423] signal handler doesn't handle SIGABRT from os.abort
In-Reply-To: <1309197130.0.0.320444785748.issue12423@psf.upfronthosting.co.za>
Message-ID: <1309294801.76.0.361023264372.issue12423@psf.upfronthosting.co.za>


Kamil Kisiel <kamil at kamilkisiel.net> added the comment:

The application is interfacing with a C library that uses abort() to signal fatal errors (horrible, I know..). Instead of core dumping I would like to be able to handle these errors at the Python level and do something else. It's starting to sound like that might be impossible.

You explanation of the abort() behaviour makes sense to me. However, if that's the case then this portion of the docs appears to be incorrect:

"Be aware that programs which use signal.signal() to register a handler for SIGABRT will behave differently."

Maybe my interpretation is wrong, but I would read "behave differently" as "call the signal handler instead" in this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12423>
_______________________________________

From report at bugs.python.org  Tue Jun 28 23:15:03 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 28 Jun 2011 21:15:03 +0000
Subject: [issue12417] Inappropriate copyright on profile files
In-Reply-To: <1309159902.95.0.523889608619.issue12417@psf.upfronthosting.co.za>
Message-ID: <1309295703.81.0.476746465931.issue12417@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I think we should apply this to earlier applicable versions too.  I would accept this change for Python 2.6.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12417>
_______________________________________

From report at bugs.python.org  Tue Jun 28 23:53:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jun 2011 21:53:12 +0000
Subject: [issue12423] signal handler doesn't handle SIGABRT from os.abort
In-Reply-To: <1309197130.0.0.320444785748.issue12423@psf.upfronthosting.co.za>
Message-ID: <1309297992.27.0.906943597602.issue12423@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"Be aware that programs which use signal.signal() to register a handler for SIGABRT will behave differently."

I don't understand this sentence. I think that this sentence should be removed, and another should maybe be added. E.g. "os.abort() doesn't call the Python signal handler installed by signal.signal()."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12423>
_______________________________________

From report at bugs.python.org  Wed Jun 29 00:25:17 2011
From: report at bugs.python.org (Brian Hare)
Date: Tue, 28 Jun 2011 22:25:17 +0000
Subject: [issue12435] Input function does not strip trailing '\r' from string
	input
In-Reply-To: <1309299917.58.0.776675076833.issue12435@psf.upfronthosting.co.za>
Message-ID: <1309299917.58.0.776675076833.issue12435@psf.upfronthosting.co.za>


New submission from Brian Hare <hareb at umkc.edu>:

In Windows, using python 3.2, the built-input function does not strip the trailing '\r' from the string input:

Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> input('Enter > ')
Enter > abcde
'abcde\r'
>>>

This behavior does not appear in IDLE but does appear in a free-standing command window. 

While the docs only say that the trailing newline is dropped, the 2.6 docs for raw_input have exactly the same wording and the carriage return is dropped:

Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> raw_input('Enter > ')
Enter > abcde
'abcde'
>>>

----------
components: Windows
messages: 139379
nosy: BKHare
priority: normal
severity: normal
status: open
title: Input function does not strip trailing '\r' from string input
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12435>
_______________________________________

From report at bugs.python.org  Wed Jun 29 00:36:18 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 28 Jun 2011 22:36:18 +0000
Subject: [issue12435] Input function does not strip trailing '\r' from string
	input
In-Reply-To: <1309299917.58.0.776675076833.issue12435@psf.upfronthosting.co.za>
Message-ID: <1309300578.07.0.143485779069.issue12435@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/issue12435>
_______________________________________

From report at bugs.python.org  Wed Jun 29 00:42:10 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 28 Jun 2011 22:42:10 +0000
Subject: [issue12435] Input function does not strip trailing '\r' from string
	input
In-Reply-To: <1309299917.58.0.776675076833.issue12435@psf.upfronthosting.co.za>
Message-ID: <1309300930.41.0.0580044960292.issue12435@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Already fixed with issue11272, which will be included in 3.2.1 and 3.3.

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed
superseder:  -> input() has trailing carriage return on windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12435>
_______________________________________

From report at bugs.python.org  Wed Jun 29 01:56:35 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 28 Jun 2011 23:56:35 +0000
Subject: [issue12436] Provide reference to detailed installation instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The Boston Python Workshop folks have some detailed step-by-step instructions on getting Python up and running ([1]).

Given that this can be a pain point for new users (primarily on Windows), it may be good to reference these instructions from the official docs. (Alternatively, we could use them as the basis for a "HOWTO" in the official docs and update release.py to adjust the relevant links. That's a lot more work than just adding a link, though)

[1] http://openhatch.org/wiki/Boston_Python_Workshop_3/Friday

----------
assignee: docs at python
components: Documentation
messages: 139381
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Provide reference to detailed installation instructions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Wed Jun 29 02:07:07 2011
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 29 Jun 2011 00:07:07 +0000
Subject: [issue12437] _ctypes.dlopen does not include errno in OSError
In-Reply-To: <1309306027.41.0.167603787283.issue12437@psf.upfronthosting.co.za>
Message-ID: <1309306027.41.0.167603787283.issue12437@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

_ctypes.dlopen is not including the errno when it raises OSError.

This occurs when attempting to load a library that doesn't exist, the error string given is clearly generated from an ENOENT.

joiner at dbssyd800:~$ python3 dlopen_raise.py
None
somelib.so: cannot open shared object file: No such file or directory

----------
components: ctypes
files: dlopen_raise.py
messages: 139382
nosy: anacrolix
priority: normal
severity: normal
status: open
title: _ctypes.dlopen does not include errno in OSError
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22512/dlopen_raise.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12437>
_______________________________________

From report at bugs.python.org  Wed Jun 29 02:08:39 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 29 Jun 2011 00:08:39 +0000
Subject: [issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl
	8.5.9 (Cocoa)
In-Reply-To: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>
Message-ID: <1309306119.39.0.412204986013.issue10736@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

No obvious buildbot problems so far so I'm going to close this as fixed.  Thanks for the patch, Ronald.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10736>
_______________________________________

From report at bugs.python.org  Wed Jun 29 02:18:58 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 29 Jun 2011 00:18:58 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1309306738.47.0.593513978328.issue8746@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Wed Jun 29 02:21:51 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 29 Jun 2011 00:21:51 +0000
Subject: [issue12141] sysconfig.get_config_vars('srcdir') fails in specific
	cases
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1309306911.63.0.222142366463.issue12141@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Wed Jun 29 02:52:45 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 29 Jun 2011 00:52:45 +0000
Subject: [issue12172] IDLE crashes when I use F5 to run
In-Reply-To: <1306297960.86.0.861957581739.issue12172@psf.upfronthosting.co.za>
Message-ID: <1309308765.87.0.789697849558.issue12172@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Since there's been no response and I believe the problem should not occur with a properly installed Python 3.2 and ActiveState Tcl 8.5 as described here (http://www.python.org/download/mac/tcltk/), I'm going to close this issue.  Please reopen if the problem persists and you can supply more supporting information.

----------
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12172>
_______________________________________

From report at bugs.python.org  Wed Jun 29 03:06:31 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Wed, 29 Jun 2011 01:06:31 +0000
Subject: [issue12438] getpass error on idle
In-Reply-To: <1309309591.85.0.564668230133.issue12438@psf.upfronthosting.co.za>
Message-ID: <1309309591.85.0.564668230133.issue12438@psf.upfronthosting.co.za>


New submission from Jo?o Bernardo <jbvsmo at gmail.com>:

The getpass function is raising an error when first used on idle (Python 3.2 and 2.7.1)

The next time it'll work "as expected" (it echoes the data, but idle is just for testing purposes so no problems here)

>>> from getpass import getpass
>>> p = getpass()
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    p = getpass()
  File "/usr/lib/python3.2/getpass.py", line 55, in unix_getpass
    passwd = fallback_getpass(prompt, stream)
  File "/usr/lib/python3.2/getpass.py", line 114, in fallback_getpass
    stacklevel=2)
  File "/usr/lib/python3.2/idlelib/PyShell.py", line 62, in idle_showwarning
    lineno, file=file, line=line))
TypeError: idle_formatwarning() got an unexpected keyword argument 'file'
>>> p = getpass()
Warning: Password input may be echoed.
Password: ok

>>> p
'ok'
>>> 



Looking at the "/usr/lib/python3.2/idlelib/PyShell.py" file the "idle_formatwarning" function don't have the "file" argument so it should be revomed from the function call at line 61:

file.write(warnings.formatwarning(message, category, filename,
                                  lineno, file=file, line=line))

----------
components: IDLE
messages: 139385
nosy: JBernardo
priority: normal
severity: normal
status: open
title: getpass error on idle
type: crash
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12438>
_______________________________________

From report at bugs.python.org  Wed Jun 29 03:08:34 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 29 Jun 2011 01:08:34 +0000
Subject: [issue12379] build outside source fail in head
In-Reply-To: <1308600053.87.0.881101721168.issue12379@psf.upfronthosting.co.za>
Message-ID: <1309309714.19.0.00047312406696.issue12379@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Fixed by Benjamin in f8f1d5691ae8.

----------
nosy: +ned.deily
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12379>
_______________________________________

From report at bugs.python.org  Wed Jun 29 03:09:40 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 29 Jun 2011 01:09:40 +0000
Subject: [issue12437] _ctypes.dlopen does not include errno in OSError
In-Reply-To: <1309306027.41.0.167603787283.issue12437@psf.upfronthosting.co.za>
Message-ID: <1309309780.53.0.0716273205432.issue12437@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

On Windows:

>>> try:
...     ctypes.CDLL('somelib')
... except OSError as exc:
...     print repr(exc)
...     print exc.errno
...
WindowsError(126, 'The specified module could not be found')
22

----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12437>
_______________________________________

From report at bugs.python.org  Wed Jun 29 03:31:36 2011
From: report at bugs.python.org (Jacob Perkins)
Date: Wed, 29 Jun 2011 01:31:36 +0000
Subject: [issue12361] Memory Leak in File Logging
In-Reply-To: <1308440220.9.0.536544421463.issue12361@psf.upfronthosting.co.za>
Message-ID: <1309311096.21.0.467327552174.issue12361@psf.upfronthosting.co.za>


Jacob Perkins <japerk at gmail.com> added the comment:

Sorry about this. Turns out the flattening of memory usage was a temporary coincidence, and I eventually tracked the bug down to an old version of MySQLdb.

----------
resolution:  -> invalid
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12361>
_______________________________________

From report at bugs.python.org  Wed Jun 29 04:57:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 02:57:30 +0000
Subject: [issue12417] Inappropriate copyright on profile files
In-Reply-To: <1309159902.95.0.523889608619.issue12417@psf.upfronthosting.co.za>
Message-ID: <E1Qbky1-0007dx-24@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 02150e60636b by Benjamin Peterson in branch '2.6':
update profile license (closes #12417)
http://hg.python.org/cpython/rev/02150e60636b

New changeset 633597815463 by Benjamin Peterson in branch '3.1':
update profile license (closes #12417)
http://hg.python.org/cpython/rev/633597815463

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12417>
_______________________________________

From report at bugs.python.org  Wed Jun 29 05:24:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 03:24:48 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <E1QblOR-0001jG-1v@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 29c670f0d7d5 by Ned Deily in branch '2.7':
Issue #9516: Correct and expand OS X deployment target tests in distutils
http://hg.python.org/cpython/rev/29c670f0d7d5

New changeset 01434498e55e by Ned Deily in branch '2.7':
Issue #9516: Change distutils to no longer globally attempt to check and
http://hg.python.org/cpython/rev/01434498e55e

New changeset e9e1fb4e3752 by Ned Deily in branch '2.7':
Issue #9516: Update Misc/NEWS.
http://hg.python.org/cpython/rev/e9e1fb4e3752

New changeset bb89023191a0 by Ned Deily in branch '3.2':
Issue #9516: Correct and expand OS X deployment target tests in distutils
http://hg.python.org/cpython/rev/bb89023191a0

New changeset b95eee310931 by Ned Deily in branch '3.2':
Issue #9516: Change distutils to no longer globally attempt to check and
http://hg.python.org/cpython/rev/b95eee310931

New changeset 8e0cfba9c8c4 by Ned Deily in branch '3.2':
Issue #9516: Update Misc/NEWS.
http://hg.python.org/cpython/rev/8e0cfba9c8c4

New changeset 371a818687a5 by Ned Deily in branch 'default':
Issue #9516: Merge Distutils changes from 3.2
http://hg.python.org/cpython/rev/371a818687a5

New changeset 47b670d386cd by Ned Deily in branch 'default':
Issue #9516: Port OS X deployment target tests from distutils to packaging
http://hg.python.org/cpython/rev/47b670d386cd

New changeset c1ae16fce76d by Ned Deily in branch 'default':
Issue #9516: Port the revised deployment target processing for OSX from
http://hg.python.org/cpython/rev/c1ae16fce76d

New changeset 1bd45742751b by Ned Deily in branch 'default':
Issue #9516: Update Misc/NEWS to include packaging.
http://hg.python.org/cpython/rev/1bd45742751b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Wed Jun 29 05:40:51 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 29 Jun 2011 03:40:51 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1309318851.41.0.203066626102.issue9516@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

While I am a little concerned about applying these fixes, it is clear that the previous behavior was broken and the initial set of patches as applied did not improve matters. The only risk I can see is that there is a slight chance that there *might* be some 3rd-party package that unknowingly depended on the previous behavior of setting MACOSX_DEPLOYMENT_TARGET globally and which might now fail.  There is no simple way to find such packages short of attempting to build them and test them.  However, if there *should* be such packages, the simple fix for them is to export the desired MACOSX_DEPLOYMENT_TARGET value into the interpreter process (via a shell variable, for instance).  So, I think it best to bite the bullet.  I've applied the Distutils patches to 2.7 (for 2.7.3), to 3.2 (for 3.2.1), to default (for 3.3) and the packaging patches to default (for 3.3).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Wed Jun 29 07:04:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Jun 2011 05:04:08 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1309323848.2.0.716545465495.issue10403@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

So I'm -1 on using "attributes" to denote methods. It will actively confuse non-expert users. If you want to ditch "members", please consider using the more explicit phrase "attributes and methods".

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Wed Jun 29 07:18:50 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 29 Jun 2011 05:18:50 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1309323848.2.0.716545465495.issue10403@psf.upfronthosting.co.za>
Message-ID: <20110629051845.GA2273@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Yes, I agree with you. Good Suggestion. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Wed Jun 29 07:23:00 2011
From: report at bugs.python.org (Cesare Di Mauro)
Date: Wed, 29 Jun 2011 05:23:00 +0000
Subject: [issue12407] test_subinterps fails on Windows
In-Reply-To: <1308999728.78.0.684048233766.issue12407@psf.upfronthosting.co.za>
Message-ID: <1309324980.5.0.360947859352.issue12407@psf.upfronthosting.co.za>


Cesare Di Mauro <cesare.di.mauro at gmail.com> added the comment:

Unfortunately this test isn't skip on normal setup (using VisualStudio 2008 Express). I've updated the clone just a few minutes ago, rebuilt Python (in Debug mode), and that's what happened:

D:\CPython>PCbuild\python_d.exe Lib\test\test_capi.py
test_instancemethod (__main__.CAPITest) ... ok
test_memoryview_from_NULL_pointer (__main__.CAPITest) ... ok
test_no_FatalError_infinite_loop (__main__.CAPITest) ... ok
test_pendingcalls_non_threaded (__main__.TestPendingCalls) ... ok
test_pendingcalls_threaded (__main__.TestPendingCalls) ... ok
test (__main__.Test6012) ... ok
test_subinterps (__main__.EmbeddingTest) ... ERROR

======================================================================
ERROR: test_subinterps (__main__.EmbeddingTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_capi.py", line 155, in test_subinterps
    os.chdir(basepath)
WindowsError: [Error 123] La sintassi del nome del file, della directory o del volume non ? corretta: ''

----------------------------------------------------------------------
Ran 7 tests in 4.587s

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib\test\test_capi.py", line 212, in <module>
    test_main()
  File "Lib\test\test_capi.py", line 176, in test_main
    support.run_unittest(CAPITest, TestPendingCalls, Test6012, EmbeddingTest)
  File "D:\CPython\lib\test\support.py", line 1280, in run_unittest
    _run_suite(suite)
  File "D:\CPython\lib\test\support.py", line 1263, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib\test\test_capi.py", line 155, in test_subinterps
    os.chdir(basepath)
WindowsError: [Error 123] La sintassi del nome del file, della directory o del volume non ? corretta: ''

[90425 refs]

The patch ensures that this test isn't always executed on Windows, as expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12407>
_______________________________________

From report at bugs.python.org  Wed Jun 29 08:21:53 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 29 Jun 2011 06:21:53 +0000
Subject: [issue11549] Build-out an AST optimizer,
	moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1309328513.57.0.298034279065.issue11549@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Marking the PEP 380 implementation as a dependency, as I expect it to be easier to update this patch to cope with those changes than it would be the other way around.

----------
dependencies: +PEP 380 reference implementation for 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11549>
_______________________________________

From report at bugs.python.org  Wed Jun 29 08:51:43 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 29 Jun 2011 06:51:43 +0000
Subject: [issue12417] Inappropriate copyright on profile files
In-Reply-To: <1309159902.95.0.523889608619.issue12417@psf.upfronthosting.co.za>
Message-ID: <1309330303.5.0.479563120448.issue12417@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Thanks Benjamin!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12417>
_______________________________________

From report at bugs.python.org  Wed Jun 29 09:13:09 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 29 Jun 2011 07:13:09 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1309286706.17.0.129322185731.issue12352@psf.upfronthosting.co.za>
Message-ID: <BANLkTim1fEsWRQB2fxqPh0KeuE+8LZStcw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Nice work! I also think heap_gc_deadlock_lockless.diff is good, except for Victor's reservation: is it deliberate that you reversed the following two statements in _free_pending_blocks(), compared to the code in free()?
>
> + ? ? ? ? ? ?self._free(block)
> + ? ? ? ? ? ?self._allocated_blocks.remove(block)
>

No, it's not deliberate (it shouldn't have any impact since they're
protected by the mutex though).
As for calling _free_pending_blocks() a second time, I'm not sure
that's necessary, I find the code simpler and cleaner that way.
I'll provide a new patch in a couple days (no access to my development
box right now).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________

From report at bugs.python.org  Wed Jun 29 09:29:10 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 29 Jun 2011 07:29:10 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1309220753.88.0.301103656267.issue12303@psf.upfronthosting.co.za>
Message-ID: <BANLkTimHX7WevveY9Y9-6+WJh8Z2fj9M4w@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Oh, the problem is that sigwait() behaviour changes after a fork: it is interrupted if an unexpected signal is received, but the signal handler is not called. It behaves correctly (the signal handler is called) without the fork.
>

Reminds me of http://bugs.python.org/issue8407#msg138066

But I think we could just remove this test: honestly, I'm not sure
that checking the behavior in case of delivery of an unblocked signal
is really useful, especially since the behavior is not clearly
defined, see POSIX man page:
"""
The sigwaitinfo() and sigtimedwait() functions may fail if:

[EINTR]
The wait was interrupted by an unblocked, caught signal. It will be
documented in system documentation whether this error will cause these
functions to fail.
"""

"may fail" [...] "It will be documented in system documentation"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Wed Jun 29 10:43:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 08:43:53 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>
Message-ID: <E1QbqND-0001f8-TA@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 00ca0c2c7bc0 by Victor Stinner in branch 'default':
Issue #12303: run sig*wait*() tests in a subprocesss
http://hg.python.org/cpython/rev/00ca0c2c7bc0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Wed Jun 29 10:45:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jun 2011 08:45:56 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>
Message-ID: <1309337156.47.0.687984351588.issue12303@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> But I think we could just remove this test

The test pass on Linux and FreeBSD 6 using a subprocess. I commited my patch to replace fork() by subprocess, let's see how it works on buildbots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Wed Jun 29 11:35:25 2011
From: report at bugs.python.org (Yoav Weiss)
Date: Wed, 29 Jun 2011 09:35:25 +0000
Subject: [issue12439] BaseHTTPServer's send_reponse adds extra "\r\n" when
	using HTTPMessage in input
In-Reply-To: <1309340125.43.0.831188381846.issue12439@psf.upfronthosting.co.za>
Message-ID: <1309340125.43.0.831188381846.issue12439@psf.upfronthosting.co.za>


New submission from Yoav Weiss <yoav.weiss.fr at gmail.com>:

I'm using BaseHTTPServer's send_response (from within a class that inherits BaseHTTPRequestHandler) with the following:

    self.send_response(response.code, response.headers)
    self.end_headers()
    self.wfile.write(content)
    self.wfile.flush()
When response is a httplib's HTTPResponse object, and its headers inherits from rfc822.Message.

What I see is that message is printed as is, including all the headers trailing "\r\n", after which the send_response method (BaseHTTPServer.py:381) adds another "\r\n".
Then send_response adds the "Server" and "Date" headers.
Since the headers before Server & Date include "\r\n\r\n", Date & server are considered by the browser as the content.

Am I misusing BaseHTTPServer? If not, this is a bug and "\r\n" should be removed from line 381, or added only after a check that shows they are not already there at the headers end, or in case there are no input headers.

----------
components: Library (Lib)
messages: 139401
nosy: Yoav.Weiss
priority: normal
severity: normal
status: open
title: BaseHTTPServer's send_reponse adds extra "\r\n" when using HTTPMessage in input
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12439>
_______________________________________

From report at bugs.python.org  Wed Jun 29 11:48:42 2011
From: report at bugs.python.org (Michael Foord)
Date: Wed, 29 Jun 2011 09:48:42 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1309340922.71.0.421664468816.issue7117@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Wondered if you guys had heard of some recent advances in the state of the art in this field. I'm sure you have, but thought I'd link it here anywhere.

Quote taken from this article (which links to relevant papers):

http://www.serpentine.com/blog/2011/06/29/here-be-dragons-advances-in-problems-you-didnt-even-know-you-had/

In 2010, Florian Loitsch published a wonderful paper in PLDI, "Printing floating-point numbers quickly and accurately with integers", which represents the biggest step in this field in 20 years: he mostly figured out how to use machine integers to perform accurate rendering! Why do I say "mostly"? Because although Loitsch's "Grisu3" algorithm is very fast, it gives up on about 0.5% of numbers, in which case you have to fall back to Dragon4 or a derivative.

If you're a language runtime author, the Grisu algorithms are a big deal: Grisu3 is about 5 times faster than the algorithm used by printf in GNU libc, for instance. A few language implementors have already taken note: Google hired Loitsch, and the Grisu family acts as the default rendering algorithms in both the V8 and Mozilla Javascript engines (replacing David Gay's 17-year-old dtoa code). Loitsch has kindly released implementations of his Grisu algorithms as a library named double-conversion.

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Wed Jun 29 12:12:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jun 2011 10:12:59 +0000
Subject: [issue12440] test_ssl.test_options() failure on Snow Leopard: can't
	clear options before OpenSSL 0.9.8m
In-Reply-To: <1309342379.37.0.935876078434.issue12440@psf.upfronthosting.co.za>
Message-ID: <1309342379.37.0.935876078434.issue12440@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Seen on "AMD64 Snow Leopard 2 3.x" buildbot:

=====================================================================
ERROR: test_options (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/test/test_ssl.py", line 81, in f
    return func(*args, **kwargs)
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/test/test_ssl.py", line 362, in test_options
    ctx.options = (ctx.options & ~ssl.OP_NO_SSLv2) | ssl.OP_NO_TLSv1
ValueError: can't clear options before OpenSSL 0.9.8m

http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%203.x/builds/581/steps/test/logs/stdio

I think that the regression was introduced by one of the following build (build 571 didn't run the test suite):

http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%203.x/builds/571
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%203.x/builds/572

----------
components: Library (Lib)
messages: 139403
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: test_ssl.test_options() failure on Snow Leopard: can't clear options before OpenSSL 0.9.8m
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12440>
_______________________________________

From report at bugs.python.org  Wed Jun 29 12:20:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Jun 2011 10:20:10 +0000
Subject: [issue12440] test_ssl.test_options() failure on Snow Leopard: can't
	clear options before OpenSSL 0.9.8m
In-Reply-To: <1309342379.37.0.935876078434.issue12440@psf.upfronthosting.co.za>
Message-ID: <1309342810.87.0.86154745275.issue12440@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The OpenSSL version linked against is "OpenSSL 0.9.8r 8 Feb 2011", but apparently the source headers are still those for an earlier version, hence the apparent failure (the headers don't have the necessary API).
Bill, could you please upgrade the OpenSSL headers on that buildbot to match the runtime version (if that's possible)?

----------
assignee:  -> janssen
keywords: +buildbot
nosy: +janssen
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12440>
_______________________________________

From report at bugs.python.org  Wed Jun 29 12:40:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Jun 2011 10:40:16 +0000
Subject: [issue12139] Add CCC command support to ftplib
In-Reply-To: <1306001340.71.0.345746598563.issue12139@psf.upfronthosting.co.za>
Message-ID: <1309344016.79.0.935465669993.issue12139@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12139>
_______________________________________

From report at bugs.python.org  Wed Jun 29 13:04:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 11:04:24 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <E1QbsZD-0005fC-0X@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 949e0c0f5a38 by Victor Stinner in branch '3.2':
Issue #12400: regrtest -W doesn't rerun the tests twice anymore, but captures
http://hg.python.org/cpython/rev/949e0c0f5a38

New changeset 0172d40fdcd4 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12400: regrtest -W doesn't rerun the tests twice anymore,
http://hg.python.org/cpython/rev/0172d40fdcd4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 13:18:39 2011
From: report at bugs.python.org (Juanjo Alvarez)
Date: Wed, 29 Jun 2011 11:18:39 +0000
Subject: [issue12441] _GLOBAL_DEFAULT_TIMEOUT remains as an object() in
	HTTPConnection and the connection hangs
In-Reply-To: <1309346319.84.0.970353674809.issue12441@psf.upfronthosting.co.za>
Message-ID: <1309346319.84.0.970353674809.issue12441@psf.upfronthosting.co.za>


New submission from Juanjo Alvarez <juanjux at gmail.com>:

I was testing a jsonrpc server using a small Python client. I noticed that sometimes when the RPC returned some long test, the response object returned by URLOpener.open(), in my case an HTTPResponse, would hang about 70% of the time when calling read() on a RPC method returning more text than usual (a string of about 4000 bytes).

Investigating it I noticed that on HTTPConnection.connect, the self.timeout value was "object". I tried to hardcode some value on the method first line, changing the "self.timeout" for "5":

self.sock = socket.create_connection((self.host,self.port),self.timeout, self.source_address)

Then suddenly the call to the RPC works 100% of the time, and I don't mean that it timeouts, it just works and doesn't hangs. So the workaround that I'm using is to call socket.setdefaulttimeout in my client code.

I saw that the default value in HTTPConnection for self.timeout is socket._GLOBAL_DEFAULT_TIMEOUT which is initialized as an "object()" and remains that way on my HTTPConnection.connect call. My guess is that when the RPC call is not very fast, the system checks the socket timeout and then it hangs if the value is an object, so the longer the text returned by the RPC, the higher the chance that the read() hangs.

----------
components: IO
messages: 139406
nosy: juanjux
priority: normal
severity: normal
status: open
title: _GLOBAL_DEFAULT_TIMEOUT remains as an object() in HTTPConnection and the connection hangs
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12441>
_______________________________________

From report at bugs.python.org  Wed Jun 29 13:19:18 2011
From: report at bugs.python.org (Juanjo Alvarez)
Date: Wed, 29 Jun 2011 11:19:18 +0000
Subject: [issue12441] _GLOBAL_DEFAULT_TIMEOUT remains as an object() in
	HTTPConnection and the connection hangs
In-Reply-To: <1309346319.84.0.970353674809.issue12441@psf.upfronthosting.co.za>
Message-ID: <1309346358.34.0.213596620411.issue12441@psf.upfronthosting.co.za>


Juanjo Alvarez <juanjux at gmail.com> added the comment:

PS: This only happens to my on Windows XP, works perfectly under Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12441>
_______________________________________

From report at bugs.python.org  Wed Jun 29 13:23:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 11:23:39 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <E1Qbsrq-0007E4-Az@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset af799df478c6 by Victor Stinner in branch 'default':
Issue #12400: oops, remove debug code...
http://hg.python.org/cpython/rev/af799df478c6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 13:24:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 11:24:56 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <E1Qbst4-0007HK-QN@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 69e102bfed2b by Victor Stinner in branch '3.2':
Issue #12400: remove unused variable
http://hg.python.org/cpython/rev/69e102bfed2b

New changeset 9d53612333c7 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12400: remove unused import
http://hg.python.org/cpython/rev/9d53612333c7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 13:34:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jun 2011 11:34:13 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <1309347253.98.0.540046961214.issue12400@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I will not backport the change in Python 2.7, because regrtest already captures stdout (but not in verbose mode), and it checks that the output is empty.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 13:43:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 11:43:49 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <E1QbtBM-0000Pn-CB@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 80c7d63325f6 by Victor Stinner in branch 'default':
Issue #12400: fix test_faulthandler if regrtest captures sys.stderr
http://hg.python.org/cpython/rev/80c7d63325f6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 14:59:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 12:59:38 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <E1QbuMi-00089a-Sr@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 74c6afbb524a by Victor Stinner in branch '3.2':
Issue #12400: don't use sys.stderr in test_kqueue because it may be replaced by
http://hg.python.org/cpython/rev/74c6afbb524a

New changeset c0afc8d00c0a by Victor Stinner in branch 'default':
(merge 3.2) Issue #12400: don't use sys.stderr in test_kqueue because it may be
http://hg.python.org/cpython/rev/c0afc8d00c0a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 15:10:45 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Jun 2011 13:10:45 +0000
Subject: [issue12438] IDLE problem displaying warning message
In-Reply-To: <1309309591.85.0.564668230133.issue12438@psf.upfronthosting.co.za>
Message-ID: <1309353045.53.0.675433897422.issue12438@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The problem isn't with getpass, the problem is that getpass is generating a warning message on first call and idle isn't handling that correctly.  Your suggested fix is probably correct.

----------
nosy: +r.david.murray, terry.reedy
stage:  -> needs patch
title: getpass error on idle -> IDLE problem displaying warning message
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12438>
_______________________________________

From report at bugs.python.org  Wed Jun 29 15:19:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Jun 2011 13:19:25 +0000
Subject: [issue12439] BaseHTTPServer's send_reponse adds extra "\r\n" when
	using HTTPMessage in input
In-Reply-To: <1309340125.43.0.831188381846.issue12439@psf.upfronthosting.co.za>
Message-ID: <1309353565.29.0.847959744779.issue12439@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12439>
_______________________________________

From report at bugs.python.org  Wed Jun 29 15:26:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 13:26:02 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <E1QbumH-0002HS-9x@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6c54c334ea7a by Victor Stinner in branch '3.2':
Issue #12400: runtest() reuses the same io.StringIO instance for all calls
http://hg.python.org/cpython/rev/6c54c334ea7a

New changeset 8897c755633b by Victor Stinner in branch 'default':
(merge 3.2) Issue #12400: runtest() reuses the same io.StringIO instance for
http://hg.python.org/cpython/rev/8897c755633b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 15:38:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 13:38:50 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <E1Qbuye-0003dB-Ll@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2d07b1b4466a by Victor Stinner in branch '3.2':
Issue #12400: regrtest, force verbose mode to True with option -W
http://hg.python.org/cpython/rev/2d07b1b4466a

New changeset 561974b760eb by Victor Stinner in branch 'default':
(merge 3.2) Issue #12400: regrtest, force verbose mode to True with option -W
http://hg.python.org/cpython/rev/561974b760eb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 15:54:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 13:54:08 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <E1QbvDS-000529-LD@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d8ba59de860a by Victor Stinner in branch '3.2':
Issue #12400: test.support.run_doctest() doesn't change sys.stdout anymore
http://hg.python.org/cpython/rev/d8ba59de860a

New changeset bb7c9308c846 by Victor Stinner in branch 'default':
Issue #12400: test.support.run_doctest() doesn't change sys.stdout anymore
http://hg.python.org/cpython/rev/bb7c9308c846

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 16:02:35 2011
From: report at bugs.python.org (Luke Plant)
Date: Wed, 29 Jun 2011 14:02:35 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1309356155.28.0.815192482706.issue2193@psf.upfronthosting.co.za>


Luke Plant <L.Plant.98 at cantab.net> added the comment:

First, I agree with others who say that RFCs are basically irrelevant for cookies. For Django we've discovered this in various ways e.g. issue 9824 - http://bugs.python.org/issue9824 - which has now been applied. We have also had to work around the stdlib behaviour here.

Second, I have implemented a patch for this, with tests, against trunk - please review.

After looking at the implementation, this seems like the best way to make Python conservative in what is produces and liberal in what it accepts, which seems to be what the thread converged on. BaseCookie will now silently discard cookie 'morsels' with a colon in their name (and all other irregularities) when loading from a string, rather than raise an exception.

This allows cookie parsing to continue, so that other cookies in the HTTP header will be found.

However, if in Python code you attempt to directly set a morsel with an illegal name, you will still get the error.

There is a more lax strategy: Simply add ':' to the _LegalChars variable.

This would allow morsels to be *read* that have a colon in their name. However, from the current implementation, it would be very hard to add that ability without also allowing the BaseCookie class to produce such cookies. This would also raise other issues about at what point an error should be raised for setting invalid cookies etc.

Also, allowing these illegal cookies to be read is a corner case that is much less important - it isn't needed either for Trac or for our needs in Django.

For these reasons, I decided against the more lax strategy.

----------
keywords: +patch
nosy: +spookylukey
Added file: http://bugs.python.org/file22513/issue2193_patch_trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jun 29 16:03:30 2011
From: report at bugs.python.org (Luke Plant)
Date: Wed, 29 Jun 2011 14:03:30 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1309356210.44.0.887710092884.issue2193@psf.upfronthosting.co.za>


Luke Plant <L.Plant.98 at cantab.net> added the comment:

Same patch backported to python 2.7 branch

----------
Added file: http://bugs.python.org/file22514/issue2193_patch_python27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jun 29 16:12:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Jun 2011 14:12:02 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1308995950.75.0.288905614048.issue12406@psf.upfronthosting.co.za>
Message-ID: <1309356722.29.0.904758142165.issue12406@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Packaging has two wininst*.exe files that distutils has not.  If the code already uses a glob, it should be fine; if it uses a fixed list, then we have to add an if block.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12406>
_______________________________________

From report at bugs.python.org  Wed Jun 29 16:25:45 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Jun 2011 14:25:45 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <1309357545.84.0.742054024146.issue12400@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  I thought Antoine got rid of the output checking when he added -j support.  Well, he was the one who did it, anyway, so there may be a change set you could backport to get rid of the output checking if you want to backport this to 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 16:31:09 2011
From: report at bugs.python.org (Luke Plant)
Date: Wed, 29 Jun 2011 14:31:09 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1309357869.73.0.654679906853.issue2193@psf.upfronthosting.co.za>


Luke Plant <L.Plant.98 at cantab.net> added the comment:

Found a bug with patch - this supersedes old one.

----------
Added file: http://bugs.python.org/file22515/issue2193_patch_2_trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jun 29 16:31:29 2011
From: report at bugs.python.org (Luke Plant)
Date: Wed, 29 Jun 2011 14:31:29 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1309357889.89.0.610224888535.issue2193@psf.upfronthosting.co.za>


Luke Plant <L.Plant.98 at cantab.net> added the comment:

Same against Python 2.7

----------
Added file: http://bugs.python.org/file22516/issue2193_patch_2_python27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jun 29 16:32:46 2011
From: report at bugs.python.org (Luke Plant)
Date: Wed, 29 Jun 2011 14:32:46 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1309357966.74.0.699081409553.issue2193@psf.upfronthosting.co.za>


Changes by Luke Plant <L.Plant.98 at cantab.net>:


Removed file: http://bugs.python.org/file22513/issue2193_patch_trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jun 29 16:32:51 2011
From: report at bugs.python.org (Luke Plant)
Date: Wed, 29 Jun 2011 14:32:51 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1309357971.63.0.770286819778.issue2193@psf.upfronthosting.co.za>


Changes by Luke Plant <L.Plant.98 at cantab.net>:


Removed file: http://bugs.python.org/file22514/issue2193_patch_python27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jun 29 16:51:38 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 29 Jun 2011 14:51:38 +0000
Subject: [issue12431] urllib2.Request.get_full_url() broken in newer versions
	of Python
In-Reply-To: <1309268248.69.0.295956213219.issue12431@psf.upfronthosting.co.za>
Message-ID: <1309359098.58.0.812363420274.issue12431@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

As Santosa said, this was discovered and fixed in 2.7 itself, surprised that you discovered it in any release Jon. If it was from a checkout, please update.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12431>
_______________________________________

From report at bugs.python.org  Wed Jun 29 17:07:59 2011
From: report at bugs.python.org (karl)
Date: Wed, 29 Jun 2011 15:07:59 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1309360079.25.0.64298444806.issue2193@psf.upfronthosting.co.za>


karl <karl+pythonbugs at la-grange.net> added the comment:

@Luke

did you have the opportunity to look at http://greenbytes.de/tech/webdav/rfc6265.html 

If there is something which doesn't match reality in that document that would be cool to have feedback about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jun 29 17:14:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Jun 2011 15:14:34 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1309360474.72.0.0298678267985.issue10403@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m not -1 on using ?attributes? to denote methods, since they *are* and it?s not difficult to understand, and I?m not opposed either to using ?attributes? to replace ?members? (i.e. attributes that are not methods.)

For those wanting to see the raging debate: http://mail.python.org/pipermail/python-dev/2011-June/112020.html

:)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Wed Jun 29 17:17:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Jun 2011 15:17:28 +0000
Subject: [issue11363] Curses - add missing functions to doc
In-Reply-To: <1299005402.55.0.443028099437.issue11363@psf.upfronthosting.co.za>
Message-ID: <1309360648.41.0.335982129958.issue11363@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A typo slipped into the 3.2 commit: x``'\033[6;4H'``

In addition, I tried the example in my shell and got a bytes/str error; that?s probably another report.

----------
nosy: +eric.araujo
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11363>
_______________________________________

From report at bugs.python.org  Wed Jun 29 17:20:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 15:20:41 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <E1QbwZD-0005sF-Ro@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset fdb98a7ef9be by Victor Stinner in branch '3.2':
Issue #12400: Add missing import (os) to test_kqueue
http://hg.python.org/cpython/rev/fdb98a7ef9be

New changeset 37877d19c2c9 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12400: Add missing import (os) to test_kqueue
http://hg.python.org/cpython/rev/37877d19c2c9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 17:23:24 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 29 Jun 2011 15:23:24 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1309361004.73.0.627997701055.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hadn't seen that.  Interesting!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Wed Jun 29 17:30:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 15:30:20 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <E1QbwiZ-0006md-7J@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7bd23115b6c4 by Victor Stinner in branch '3.2':
Issue #12400: runtest() truncates the StringIO stream before a new test
http://hg.python.org/cpython/rev/7bd23115b6c4

New changeset fc831c49216d by Victor Stinner in branch 'default':
(merge 3.2) Issue #12400: runtest() truncates the StringIO stream before a new
http://hg.python.org/cpython/rev/fc831c49216d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 17:32:55 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Jun 2011 15:32:55 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1309361575.14.0.19902868663.issue2193@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for taking a crack at this.  IMO the thing that needs to be fixed here is that receiving an invalid cookie makes it difficult to receive the valid cookies.  I'd love to accept your patch, but "silently ignore" sounds like a bad idea and is something we try to avoid in Python where practical.  In the email package we have a mechanism for reporting RFC violations (the defects attribute).  And we make as much sense of the input as we can, even if it is invalid, and preserve it.  We even allow generation of some RFC-invalid stuff, though we have plans to make applications work harder to do that in the future.

So I think your harder fix (accept the RFC-invalid cookies as long as there is some sensible way to parse them, but reject creating them) is the right approach.  I could also see the possibility of accepting a feature request for adding the ability to explicitly create RFC-invalid cookies, if someone can demonstrate a use case for doing so.  Other possible follow-on feature requests would be a 'defects' facility and/or a way to explicitly request that non-compliant cookies be ignored.

Note that in suggesting we reject creating RFC-invalid cookies by default I am not expressing an opinion on the relevance of the RFCs to cookie processing "in the wild".  Given that there is a standard and we are talking about what to do on generation, the obvious answer (by Postel's law) is that we ought to generate standards-compliant cookies.

Also note that I have not looked at the referenced rfc (here is what I believe is the official link: http://tools.ietf.org/html/rfc6265).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jun 29 17:33:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Jun 2011 15:33:53 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <1309361633.5.0.252234301124.issue12400@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

One more time, commit messages using the present tense are ambiguous: when you write ?runtest() truncates the StringIO stream before a new test?, it?s not clear at all whether you describe the previous, incorrect behavior or the new, fixed one.  These phrasings are better:

?X used to do Y? (old behavior)
?X now does Z? (new)
?make X do Z? (new)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 17:34:00 2011
From: report at bugs.python.org (Luke Plant)
Date: Wed, 29 Jun 2011 15:34:00 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1309361640.32.0.0510299864774.issue2193@psf.upfronthosting.co.za>


Luke Plant <L.Plant.98 at cantab.net> added the comment:

I had a quick look, and there are these relevant bits:

<< There are two audiences for this specification: developers of cookie-generating servers and developers of cookie-consuming user agents. >>

And:

<< To maximize interoperability with user agents, servers should limit themselves to the well-behaved profile defined in Section 4 when generating cookies. >>

So, the document doesn't tell servers how to parse cookies, only how to generate them.

With regards to generation, there is basically no change - we still disallow programmers to set cookie names that are not a 'token', as defined by section 4 of that document, which is the same as RFC 2109 in terms of valid cookie names if you look at it. It is not obvious to me that Python's BaseCookie implementation obeys RFC 2109 (due to the way character lists are defined in the opposite way), but if you believe the comments in the module then it does.

I haven't read the rest of RFC 6265 and checked BaseCookie against it - that would be a much bigger job. But with respect to the change in my patch, it looks like we are all OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jun 29 17:40:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jun 2011 15:40:56 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1309361633.5.0.252234301124.issue12400@psf.upfronthosting.co.za>
Message-ID: <1309362049.2470.0.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> One more time, commit messages using the present tense are ambiguous:
> when you write ?runtest() truncates the StringIO stream before a new
> test?, it?s not clear at all whether you describe the previous,
> incorrect behavior or the new, fixed one.

You can guess by reading the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 17:42:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Jun 2011 15:42:48 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <1309362168.48.0.885438981173.issue12400@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It?s irrelevant, please provide unambiguous commit message.  This was discussed two or three times already.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 18:02:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Jun 2011 16:02:18 +0000
Subject: [issue12425] gettext breaks on empty plural-forms value
In-Reply-To: <1309246707.61.0.397995745183.issue12425@psf.upfronthosting.co.za>
Message-ID: <1309363338.25.0.298234094095.issue12425@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

IIUC, this comes up with invalid po files, so this report is about graceful error handling, not strictly a bug.

If https://bugzilla.redhat.com/attachment.cgi?id=489427 was applied, gettext would not fail anymore, but the invalid line would not be reported IIUC.  I think we should print an error message, to let libs/apps find the mistake.

----------
keywords: +needs review, patch
nosy: +eric.araujo, lemburg, loewis
stage:  -> patch review
type:  -> behavior
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12425>
_______________________________________

From report at bugs.python.org  Wed Jun 29 18:13:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 16:13:00 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <E1QbxNq-0002IC-R1@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bc2f3fbda7e3 by Victor Stinner in branch '3.2':
Issue #12400: test_zipimport_support doesn't restore original sys.stdout
http://hg.python.org/cpython/rev/bc2f3fbda7e3

New changeset ff5abf93db80 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12400: test_zipimport_support doesn't restore original
http://hg.python.org/cpython/rev/ff5abf93db80

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 18:14:46 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 29 Jun 2011 16:14:46 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1309356722.29.0.904758142165.issue12406@psf.upfronthosting.co.za>
Message-ID: <1309364084.97687.YahooMailRC@web25804.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Packaging has two wininst*.exe files that distutils has  not.  If the code 
>already uses a glob, it should be fine; if it uses a  fixed list, then we have 
>to add an if  block.

Yes, it's using glob :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12406>
_______________________________________

From report at bugs.python.org  Wed Jun 29 18:48:32 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 29 Jun 2011 16:48:32 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <1309366112.79.0.95473504545.issue12400@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Eric is right. I don't see the patch when reading "hg log" output, or looking up revisions given by "hg annotate".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 18:55:39 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 29 Jun 2011 16:55:39 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

Patch in attachment adds a new disk_usage() function to shutil module which retrieves total, used and free disk space given a certain path plus the percentage usage.

See original discussion on python-ideas ml:
http://mail.python.org/pipermail/python-ideas/2011-June/010480.htm

----------
assignee: giampaolo.rodola
components: Library (Lib)
files: diskusage.patch
keywords: needs review, patch
messages: 139439
nosy: giampaolo.rodola, pitrou, rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: shutil.disk_usage()
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22517/diskusage.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12442>
_______________________________________

From report at bugs.python.org  Wed Jun 29 19:02:00 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 29 Jun 2011 17:02:00 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <1309366920.88.0.596772052083.issue12442@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/issue12442>
_______________________________________

From report at bugs.python.org  Wed Jun 29 19:02:52 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 29 Jun 2011 17:02:52 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <1309366972.9.0.914716505624.issue12442@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Typo. It's:
http://mail.python.org/pipermail/python-ideas/2011-June/010480.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12442>
_______________________________________

From report at bugs.python.org  Wed Jun 29 19:52:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jun 2011 17:52:16 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1309366112.79.0.95473504545.issue12400@psf.upfronthosting.co.za>
Message-ID: <1309369929.7968.1.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Eric is right. I don't see the patch when reading "hg log" output

I'm using hg log -p.

> or looking up revisions given by "hg annotate".

hg annotate doesn't display the changelog, only the commit number or
hash, which option do you use?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 19:58:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 29 Jun 2011 17:58:54 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <1309370334.66.0.480300870086.issue12442@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/issue12442>
_______________________________________

From report at bugs.python.org  Wed Jun 29 20:03:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 18:03:37 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <E1Qbz6t-000410-2G@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 450209efe272 by Victor Stinner in branch '3.2':
Issue #12400: regrtest.runtest() uses stream.seek(0) before .truncate()
http://hg.python.org/cpython/rev/450209efe272

New changeset 3ce22f1b9540 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12400: regrtest.runtest() uses stream.seek(0) before .truncate()
http://hg.python.org/cpython/rev/3ce22f1b9540

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 20:16:18 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 29 Jun 2011 18:16:18 +0000
Subject: [issue11363] Curses - add missing functions to doc
In-Reply-To: <1299005402.55.0.443028099437.issue11363@psf.upfronthosting.co.za>
Message-ID: <1309371378.73.0.530577563764.issue11363@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I think the same typo is also on default (since merged from 3.2): Ezio, do you want me to upload a patch or you'll fix it?

?ric: I can see the tparm() example is failing, since tgetstr() is returning bytes while it expects a string: did you already file about about it? want me to?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11363>
_______________________________________

From report at bugs.python.org  Wed Jun 29 20:22:51 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Jun 2011 18:22:51 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1309371771.43.0.65071553272.issue7117@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the link :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Wed Jun 29 20:51:17 2011
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 29 Jun 2011 18:51:17 +0000
Subject: [issue12443] locale.setlocale(locale.LC_ALL,
	locale.getlocale()) fails for some locales
In-Reply-To: <1309373477.02.0.58527022305.issue12443@psf.upfronthosting.co.za>
Message-ID: <1309373477.02.0.58527022305.issue12443@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <invalid at example.invalid>:

Consider this transcript from OS X 10.6:

>>> import locale
>>> locale.getlocale()
(None, None)
>>> locale.setlocale(locale.LC_ALL, _)
'C'
>>> locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')
'en_US.UTF-8'
>>> locale.getlocale()
('en_US', 'UTF8')
>>> locale.setlocale(locale.LC_ALL, _)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/locale.py", line 494, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting
>>> 

OS X does not recognize 'en_US.UTF8', only 'en_US.UTF-8'.  However, when passed a tuple, the locale module tries to normalize the values.  It ends up turning the result of getlocale from ('en_US', 'UTF-8') into 'en_US.UTF8'.

----------
assignee: ronaldoussoren
components: Extension Modules, Library (Lib), Macintosh
messages: 139445
nosy: exarkun, ronaldoussoren
priority: normal
severity: normal
status: open
title: locale.setlocale(locale.LC_ALL, locale.getlocale()) fails for some locales
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12443>
_______________________________________

From report at bugs.python.org  Wed Jun 29 20:55:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jun 2011 18:55:23 +0000
Subject: [issue12443] locale.setlocale(locale.LC_ALL,
	locale.getlocale()) fails for some locales
In-Reply-To: <1309373477.02.0.58527022305.issue12443@psf.upfronthosting.co.za>
Message-ID: <1309373723.72.0.647180354751.issue12443@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Good news: it's a duplicate and it's already fixed! See issues #10090 and #10154. The fix is part of Python 3.1.4 (released the 12th june 2011) and Python 2.7.2 (released the 12 june 2011), and will be part of Python 3.2.1.

----------
nosy: +haypo
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12443>
_______________________________________

From report at bugs.python.org  Wed Jun 29 20:56:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jun 2011 18:56:31 +0000
Subject: [issue12443] locale.setlocale(locale.LC_ALL,
	locale.getlocale()) fails for some locales
In-Reply-To: <1309373477.02.0.58527022305.issue12443@psf.upfronthosting.co.za>
Message-ID: <1309373791.36.0.827320285314.issue12443@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(Python 2.6 only accepts security fixes, no more bug fixes. It's time to upgrade to 2.7!)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12443>
_______________________________________

From report at bugs.python.org  Wed Jun 29 22:13:07 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 29 Jun 2011 20:13:07 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <1309378387.03.0.201386797169.issue12400@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

> Eric is right. I don't see the patch when reading "hg log" output

... or when looking at the issue tracker.  Yes, one can probably figure out the intent by looking at the whole patch but it's kind of rude to force people to do that.  That's what the commit message is there for: to give a brief, unambiguous summary of what the change is about.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 22:56:37 2011
From: report at bugs.python.org (Peter Eisentraut)
Date: Wed, 29 Jun 2011 20:56:37 +0000
Subject: [issue12444] accept sets or collections for str.strip/lstrip/rstrip
In-Reply-To: <1309380997.61.0.864474637719.issue12444@psf.upfronthosting.co.za>
Message-ID: <1309380997.61.0.864474637719.issue12444@psf.upfronthosting.co.za>


New submission from Peter Eisentraut <peter_e at gmx.net>:

It appears to be a pretty common mistake to think that the argument of str.strip/lstrip/rstrip is a substring rather than a set of characters.  To allow a more clearer notation, it would be nice if these functions also accepted an argument other than a string, for example a set or any collection.  Then you could write, for example:

a.strip({'a', 'b', 'c'})

I suggest to either add support for sets specifically, or more generally anything that supports the "in" operator.

I can try to code it up if it sounds acceptable.

----------
components: Library (Lib)
messages: 139449
nosy: petere
priority: normal
severity: normal
status: open
title: accept sets or collections for str.strip/lstrip/rstrip
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12444>
_______________________________________

From report at bugs.python.org  Wed Jun 29 22:58:43 2011
From: report at bugs.python.org (John O'Connor)
Date: Wed, 29 Jun 2011 20:58:43 +0000
Subject: [issue11549] Build-out an AST optimizer,
	moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1309381123.13.0.683220616779.issue11549@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
nosy: +jcon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11549>
_______________________________________

From report at bugs.python.org  Wed Jun 29 23:26:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 21:26:32 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <E1Qc2HH-0005MN-9E@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c7bed90e4f31 by Victor Stinner in branch 'default':
Issue #12400: test_faulthandler now uses sys.__stderr__
http://hg.python.org/cpython/rev/c7bed90e4f31

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Wed Jun 29 23:46:41 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Jun 2011 21:46:41 +0000
Subject: [issue12444] accept sets or collections for str.strip/lstrip/rstrip
In-Reply-To: <1309380997.61.0.864474637719.issue12444@psf.upfronthosting.co.za>
Message-ID: <1309384001.36.0.327785379088.issue12444@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

-1 on complicating the API.  The purported problem isn't pervasive enough to warrant a change (I frequently teach python classes and do code reviews and rarely encounter this issue).  Also, the proposed change isn't going to help the people who are setting out to remove a ".html" suffix and are presuming that rstrip is the way to do it.  Those folks have already made an unfounded assumption this proposal does nothing to invalidate their experiment.  AFAICT, this proposal would only benefit someone who already knows that strip characters are accepted in all combinations (as clearly documented).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12444>
_______________________________________

From report at bugs.python.org  Wed Jun 29 23:58:20 2011
From: report at bugs.python.org (Luke Plant)
Date: Wed, 29 Jun 2011 21:58:20 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1309384700.72.0.382283050131.issue2193@psf.upfronthosting.co.za>


Luke Plant <L.Plant.98 at cantab.net> added the comment:

@ David Murray:

Thanks for taking the time to look at this - can I trouble you to keep going and read my response?

Thanks. 

You wrote:

> IMO the thing that needs to be fixed here is that receiving an invalid cookie 
> makes it difficult to receive the valid cookies.

I agree absolutely, and my patch implements exactly that aim. So I don't understand why the rest of your reply goes on to assume a very different goal - handling RFC-invalid cookies such that we can read their values. 

> I'd love to accept your patch, but "silently ignore" sounds like a bad 
> idea and is something we try to avoid in Python where practical.

"silently ignore" is what the current BaseCookie implementation does for **every other** type of invalid input, with the only exception (I can find) being the case where everything is correct apart from the name:

>>> from Cookie import SimpleCookie
>>> c = SimpleCookie()
>>> c.load('rubbish')
>>> c
<SimpleCookie: >
>>> c.output()
''
>>> c.load('more:rubbish')
>>> c
<SimpleCookie: >
>>> c.load('name=value')
>>> c
<SimpleCookie: name='value'>
>>> c.load('name=value; invalidattribute;')
>>> c.output()
'Set-Cookie: name=value'
>>> c.load('xyz123"sfs;;=-abc')
>>> c
<SimpleCookie: name='value'>
>>> c.load('namewith:colon=value')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/Cookie.py", line 632, in load
    self.__ParseString(rawdata)
  File "/usr/lib/python2.7/Cookie.py", line 665, in __ParseString
    self.__set(K, rval, cval)
  File "/usr/lib/python2.7/Cookie.py", line 585, in __set
    M.set(key, real_value, coded_value)
  File "/usr/lib/python2.7/Cookie.py", line 460, in set
    raise CookieError("Illegal key value: %s" % key)
Cookie.CookieError: Illegal key value: namewith:colon

As you said, I think this ticket is about fixing that last one, which is the gross exception to the rule, and the only thing that is causing major problems for people.

I agree that handling cookies with invalid names so that we can read them would be nice, but I think it is **very** difficult to find a rationale for saying that this bug fix should have to wait for that change.

In addition, I do not think there is any sensible way to implement that suggestion given the API of BaseCookie at the moment - it's not just the implementation I baulked at, it is the API of BaseCookie that works against you every step of the way.

The API of BaseCookie works like this in the typical case:

Consuming:

input -> load()        -> store in BaseCookie -> __getitem__()

Generating:

input -> __setitem__() -> store in BaseCookie -> output()

(Of course you don't have to do it that way, but looking at the docs and examples, http://docs.python.org/library/cookie.html, it's very clear that it's meant to be used that way).

The fact that both modes involves storing in BaseCookie really messes up any attempt to make these two work differently, and means you would have a really surprising and strange API whichever way you do it.

So, option (1): you could allow BaseCookie to store invalid cookie names if they come via load, but not via __setitem__(). This means that you've got an easy work-around for BaseCookie refusing to store your value - just use 'load()' instead. It also means that simple code like this fails:

>>> c['name:val'] = c['name:val']

which can be a problem if you are trying to do some generalised processing of the contents of a BaseCookie.

This leads us to option (2): allow RFC-invalid cookies to be stored, but then quietly sanitise (i.e. discard) in output().

But this becomes a much worse example of "silently ignoring" - the former is tolerant handling of data that is outside the programmers control - Postel's law. But this would be accepting incorrect data from a programmer, and then silently discarding it, is what we should do our utmost to avoid.

Neither of these options is any good, and it is because the API of BaseCookie was just not designed for it. The only sensible things to do, given our API, is sanitise on input. We could have an 'RFC-invalid' mode, but it would have to be turned on for the whole Cookie instance, and it would be a feature addition. An alternative implementation would be a 'badmorsels' attribute which preserves the rubbish where possible, in case you want it - but again, it's a feature addition.

Finally, I think the behaviour you are aiming at is unreasonable to ask for, especially in this ticket. You are essentially asking for a tolerant kind of cookie parsing which does its best to do 'do-what-I-mean'. But:

1) You haven't specified further than that (and there are no RFCs of use)
2) in general that kind of thing is notoriously hard to get right
3) the job is never finished - there are always more cases of invalid cookies that you *could* handle
4) and in fact it is impossible to provide an implementation that pleases everyone - there will always be invalid cookies that were 'meant' to be one thing, but the implementation interprets in a different way.

Do we really have to wait for all of that to be sorted out before we fix the glaring inconsistency in the way that BaseCookie.load() deals with some kinds of invalid data?

Thanks!

Luke

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Thu Jun 30 00:01:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Jun 2011 22:01:03 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <E1Qc2oc-0008Kg-Rk@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6edb7c153105 by Victor Stinner in branch 'default':
Issue #12400: test_cprofile now restores correctly the previous sys.stderr
http://hg.python.org/cpython/rev/6edb7c153105

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12400>
_______________________________________

From report at bugs.python.org  Thu Jun 30 00:14:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 29 Jun 2011 22:14:05 +0000
Subject: [issue12444] accept sets or collections for str.strip/lstrip/rstrip
In-Reply-To: <1309380997.61.0.864474637719.issue12444@psf.upfronthosting.co.za>
Message-ID: <1309385645.61.0.740366977369.issue12444@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/issue12444>
_______________________________________

From report at bugs.python.org  Thu Jun 30 00:59:16 2011
From: report at bugs.python.org (Tom Rini)
Date: Wed, 29 Jun 2011 22:59:16 +0000
Subject: [issue7846] Fnmatch cache is never cleared during usage
In-Reply-To: <1265209336.56.0.865162695939.issue7846@psf.upfronthosting.co.za>
Message-ID: <1309388356.08.0.0189461613874.issue7846@psf.upfronthosting.co.za>


Tom Rini <tom.rini at gmail.com> added the comment:

Did a change later make this user-configurable?  I've got some code here that now runs so slow as to be unusable because nothing is ever cached anymore.  Thanks!

----------
nosy: +Tom.Rini

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7846>
_______________________________________

From report at bugs.python.org  Thu Jun 30 01:55:27 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 29 Jun 2011 23:55:27 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1309391727.81.0.609233944557.issue9516@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Thu Jun 30 02:03:11 2011
From: report at bugs.python.org (Julian)
Date: Thu, 30 Jun 2011 00:03:11 +0000
Subject: [issue12445] dict view values objects are missing tp_richcmp and
	tp_as_number
In-Reply-To: <1309392190.89.0.80399053449.issue12445@psf.upfronthosting.co.za>
Message-ID: <1309392190.89.0.80399053449.issue12445@psf.upfronthosting.co.za>


New submission from Julian <Julian+Python.org at GrayVines.com>:

dict view values() objects are missing tp_richcmp and tp_as_sequence, and the tests for those were incomplete, which means that on 2.7 and 3.2 (and on current head) viewvalues / values objects don't compare correctly. Without indication, I assume this is not the desired behavior.

Looks like the cause is that the dictview_richcompare function was written to expect a set-like object, and nothing was written for values. I've modified it to accept any view object and do the appropriate check.

One thing I'm unsure of, which I'm sure one of you will help with, is what the desired behavior is on what values() view objects actually *should* be equal to. Being that there isn't a multiset object, and that I couldn't find any resource, I assumed that they only should be equal to other values() objects, not any of the other (ordered) containers. If that's incorrect, or if I need to discuss that on the mailing list, please let me know.

A patch to fix both is attached with the correction to the unit test, hope I did this correctly. I assume this needs to be backported to 2.7, but I figured I'd ask about that first. (Test suite runs without errors on current 3.3 head with this patch for me).

dictview_richcompare also needs unit tests for the NotImplemented error that it should return, but I didn't want to convolute this patch, please let me know if I should put that in here, or file another ticket, or neither.

Thanks!

----------
components: Interpreter Core
files: viewvalues_compare.patch
keywords: patch
messages: 139455
nosy: Julian
priority: normal
severity: normal
status: open
title: dict view values objects are missing tp_richcmp and tp_as_number
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22518/viewvalues_compare.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12445>
_______________________________________

From report at bugs.python.org  Thu Jun 30 02:09:56 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 30 Jun 2011 00:09:56 +0000
Subject: [issue12445] dict view values objects are missing tp_richcmp and
	tp_as_number
In-Reply-To: <1309392190.89.0.80399053449.issue12445@psf.upfronthosting.co.za>
Message-ID: <1309392596.66.0.631512538189.issue12445@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, rhettinger
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12445>
_______________________________________

From report at bugs.python.org  Thu Jun 30 02:42:33 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 30 Jun 2011 00:42:33 +0000
Subject: [issue12172] IDLE crashes when I use F5 to run
In-Reply-To: <1306297960.86.0.861957581739.issue12172@psf.upfronthosting.co.za>
Message-ID: <1309394553.29.0.237812305277.issue12172@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I forgot that there was another issue with F5 using IDLE on OS X when linked to Cocoa Tcl/Tk 8.5, including ActiveState 8.5; see Issue11088.  The fix for it was released in Python 2.7.2 and will be in the forthcoming Python 3.2.1 (as of rc2).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12172>
_______________________________________

From report at bugs.python.org  Thu Jun 30 03:43:26 2011
From: report at bugs.python.org (Thomas Barnet-Lamb)
Date: Thu, 30 Jun 2011 01:43:26 +0000
Subject: [issue12446] StreamReader Readlines
In-Reply-To: <1309398206.26.0.914481831308.issue12446@psf.upfronthosting.co.za>
Message-ID: <1309398206.26.0.914481831308.issue12446@psf.upfronthosting.co.za>


New submission from Thomas Barnet-Lamb <tbarnetlamb at gmail.com>:

It appears that StreamReader's readlines method behaves in a strange manner if the StreamReader has, in a previous read operation, decoded more characters than the user asked for; this happens when both the chars and size parameters are used, but only in some circumstances.

See the following:

Python 2.7.2 (default, Jun 26 2011, 02:56:25) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs
>>> 
>>> ## First make a file
... with codecs.open('temp.tmp','wb', encoding='utf8') as f:
...     f.write(u'This\u00ab is a test line\nThis is another test line\n')
... 
>>> 
>>> ## Now open it for reading 
... UTF8Reader = codecs.getreader('utf-8')
>>> with UTF8Reader(codecs.open('temp.tmp','rb')) as f:
...     print(repr(f.read(size=5, chars=5)))
...     print(f.readlines())
... 
u'This\xab'
[u' is ']
# The expected output is 
# u'This\xab'
# [u' is a test line\n', u'This is another test line\n']


I believe the culprit is codecs.py, line 466-467 (the two starred lines below). I think they ought to be replaced with 'pass'.


            if chars < 0:
                if size < 0:
*                   if self.charbuffer:
*                       break      
                elif len(self.charbuffer) >= size:
                    break

Best wishes,
Thomas

PS - I will apologize in advance for any oversights or mistakes in the formatting etc. of this bug report---this is my first time!

----------
components: Unicode
messages: 139457
nosy: Thomas.Barnet-Lamb
priority: normal
severity: normal
status: open
title: StreamReader Readlines
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12446>
_______________________________________

From report at bugs.python.org  Thu Jun 30 03:43:53 2011
From: report at bugs.python.org (Thomas Barnet-Lamb)
Date: Thu, 30 Jun 2011 01:43:53 +0000
Subject: [issue12446] StreamReader Readlines
In-Reply-To: <1309398206.26.0.914481831308.issue12446@psf.upfronthosting.co.za>
Message-ID: <1309398233.13.0.966713133354.issue12446@psf.upfronthosting.co.za>


Changes by Thomas Barnet-Lamb <tbarnetlamb at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12446>
_______________________________________

From report at bugs.python.org  Thu Jun 30 03:44:18 2011
From: report at bugs.python.org (Thomas Barnet-Lamb)
Date: Thu, 30 Jun 2011 01:44:18 +0000
Subject: [issue12446] StreamReader Readlines behavior odd
In-Reply-To: <1309398206.26.0.914481831308.issue12446@psf.upfronthosting.co.za>
Message-ID: <1309398258.56.0.43053752193.issue12446@psf.upfronthosting.co.za>


Changes by Thomas Barnet-Lamb <tbarnetlamb at gmail.com>:


----------
title: StreamReader Readlines -> StreamReader Readlines behavior odd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12446>
_______________________________________

From report at bugs.python.org  Thu Jun 30 07:22:02 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 30 Jun 2011 05:22:02 +0000
Subject: [issue12446] StreamReader Readlines behavior odd
In-Reply-To: <1309398206.26.0.914481831308.issue12446@psf.upfronthosting.co.za>
Message-ID: <1309411322.49.0.824340625032.issue12446@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
nosy: +haypo, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12446>
_______________________________________

From report at bugs.python.org  Thu Jun 30 07:45:42 2011
From: report at bugs.python.org (Matt Joiner)
Date: Thu, 30 Jun 2011 05:45:42 +0000
Subject: [issue12447] ~True is not False
In-Reply-To: <1309412742.21.0.0834751390952.issue12447@psf.upfronthosting.co.za>
Message-ID: <1309412742.21.0.0834751390952.issue12447@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

Given there is no ! operator in Python, I next tried ~ (despite that I'm after a logical not). This came as a surprise:

>>> bool(~True)
True
>>> bool(~False)
True
>>> bool(~~False)
False
>>> ~True, ~~True, ~False, ~~False
(-2, 1, -1, 0)

Is there any consideration to "fixing" this? Is int(True) 1 due to C? Why is it preferred over -1?

It seems more appropriate to me that True have:

def __invert__(self): return False
def __int__(self): return 1 # or even -1

This also "fixes" this case too:

>>> -True
-1

----------
components: Interpreter Core
messages: 139458
nosy: anacrolix
priority: normal
severity: normal
status: open
title: ~True is not False
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/issue12447>
_______________________________________

From report at bugs.python.org  Thu Jun 30 07:51:46 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 30 Jun 2011 05:51:46 +0000
Subject: [issue12447] ~True is not False
In-Reply-To: <1309412742.21.0.0834751390952.issue12447@psf.upfronthosting.co.za>
Message-ID: <1309413106.25.0.506327484173.issue12447@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Did you try the "not" operator?
http://docs.python.org/reference/expressions.html#boolean-operations

>>> not True
False
>>> not False
True

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12447>
_______________________________________

From report at bugs.python.org  Thu Jun 30 08:11:09 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 30 Jun 2011 06:11:09 +0000
Subject: [issue12447] ~True is not False
In-Reply-To: <1309412742.21.0.0834751390952.issue12447@psf.upfronthosting.co.za>
Message-ID: <1309414269.5.0.425492725866.issue12447@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is deliberate, and will not be changed (at least not until Python 4, and likely not even then). Please ask on a Python forum about history and motivation of the boolean type in Python if you want to know more.

----------
nosy: +loewis
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12447>
_______________________________________

From report at bugs.python.org  Thu Jun 30 08:20:26 2011
From: report at bugs.python.org (Matt Joiner)
Date: Thu, 30 Jun 2011 06:20:26 +0000
Subject: [issue12448] smtplib's __main__ doesn't flush when prompting
In-Reply-To: <1309414826.92.0.939740795599.issue12448@psf.upfronthosting.co.za>
Message-ID: <1309414826.92.0.939740795599.issue12448@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

The smptlib module's __main__ doesn't flush stdout when prompting:

        sys.stdout.write(prompt + ": ")
        return sys.stdin.readline().strip()

stdout is usually line buffered, and so running python3 smptlib.py doesn't actually prompt the user.

The line `sys.stdout.flush()` needs to be added.

----------
components: Library (Lib)
messages: 139461
nosy: anacrolix
priority: normal
severity: normal
status: open
title: smtplib's __main__ doesn't flush when prompting
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12448>
_______________________________________

From report at bugs.python.org  Thu Jun 30 09:27:15 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 30 Jun 2011 07:27:15 +0000
Subject: [issue12303] expose sigwaitinfo() and sigtimedwait() in the signal
	module
In-Reply-To: <1307660265.02.0.784529954936.issue12303@psf.upfronthosting.co.za>
Message-ID: <1309418835.74.0.192223269341.issue12303@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

The tests seem to be working fine on all the buildbots now...

Thanks!

----------
resolution:  -> accepted
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12303>
_______________________________________

From report at bugs.python.org  Thu Jun 30 09:31:58 2011
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 30 Jun 2011 07:31:58 +0000
Subject: [issue12449] Add accelerator "F" to button "Finish" in all MSI
	installers made by bdist_msi
In-Reply-To: <1309419118.82.0.901696442421.issue12449@psf.upfronthosting.co.za>
Message-ID: <1309419118.82.0.901696442421.issue12449@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

I noticed that in MSI installers downloaded from PyPI don't have an accelerator on the Finish button. Please add an accelerator on it. (I think that "F" is the accepted one.)

----------
assignee: tarek
components: Distutils
messages: 139463
nosy: cool-RR, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Add accelerator "F" to button "Finish" in all MSI installers made by bdist_msi
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12449>
_______________________________________

From report at bugs.python.org  Thu Jun 30 10:08:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 08:08:00 +0000
Subject: [issue12446] StreamReader Readlines behavior odd
In-Reply-To: <1309398206.26.0.914481831308.issue12446@psf.upfronthosting.co.za>
Message-ID: <1309421280.29.0.72703060045.issue12446@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8260.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12446>
_______________________________________

From report at bugs.python.org  Thu Jun 30 10:08:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 08:08:07 +0000
Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up by
	f.read() return bad result
In-Reply-To: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za>
Message-ID: <1309421287.05.0.0250550397318.issue8260@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #12446.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8260>
_______________________________________

From report at bugs.python.org  Thu Jun 30 10:19:17 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 30 Jun 2011 08:19:17 +0000
Subject: [issue12450] Use the Grisu algorithms to convert floats to strings
In-Reply-To: <1309421957.37.0.89091198831.issue12450@psf.upfronthosting.co.za>
Message-ID: <1309421957.37.0.89091198831.issue12450@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Reported by Michael Ford in msg139402:
http://www.serpentine.com/blog/2011/06/29/here-be-dragons-advances-in-problems-you-didnt-even-know-you-had/
describes a new algorithm for float<->str conversions.

It would be interesting to see if it is better/faster than the current dtoa.

----------
components: Interpreter Core
messages: 139466
nosy: amaury.forgeotdarc, mark.dickinson, michael.foord, rhettinger
priority: normal
severity: normal
status: open
title: Use the Grisu algorithms to convert floats to strings
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12450>
_______________________________________

From report at bugs.python.org  Thu Jun 30 10:19:34 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 30 Jun 2011 08:19:34 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1309421974.43.0.641697997852.issue7117@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I've filed issue12450 to track this last idea.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Thu Jun 30 10:34:30 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 30 Jun 2011 08:34:30 +0000
Subject: [issue12450] Use the Grisu algorithms to convert floats to strings
In-Reply-To: <1309421957.37.0.89091198831.issue12450@psf.upfronthosting.co.za>
Message-ID: <1309422870.36.0.78834871363.issue12450@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12450>
_______________________________________

From report at bugs.python.org  Thu Jun 30 11:31:48 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 30 Jun 2011 09:31:48 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <1309426308.91.0.331751351056.issue12442@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

New patch includes:

- Py_BEGIN/END_ALLOW_THREADS around GetDiskFreeSpaceEx() call
- use of assertGreaterEqual / assertLessEqual when testing the percentage usage
- use of hasattr(shutil, 'disk_usage') for skipping the test
- extended url reference in the comments

----------
Added file: http://bugs.python.org/file22519/diskusage2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12442>
_______________________________________

From report at bugs.python.org  Thu Jun 30 11:50:52 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 30 Jun 2011 09:50:52 +0000
Subject: [issue12450] Use the Grisu algorithms to convert floats to strings
In-Reply-To: <1309421957.37.0.89091198831.issue12450@psf.upfronthosting.co.za>
Message-ID: <1309427452.98.0.242646145139.issue12450@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12450>
_______________________________________

From report at bugs.python.org  Thu Jun 30 12:01:17 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 30 Jun 2011 10:01:17 +0000
Subject: [issue12450] Use the Grisu algorithms to convert floats to strings
In-Reply-To: <1309421957.37.0.89091198831.issue12450@psf.upfronthosting.co.za>
Message-ID: <1309428077.72.0.970355913247.issue12450@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I see the problems as:

1. Given Python's other overhead, we'd need to profile to show an improvement in the speed of this conversion would make a noticeable impact on any import workload.

2. If we want to keep the shortest-float-repr property for all possible doubles, we'd need to use Grisu3 but still keep our existing code for the fallback cases. This is a big increase in the complexity of an already complex piece of code.

I'm not saying don't switch to Grisu2 or use Grisu3 with the fallback to existing code: maybe the speed improvements are worth it, maybe we can say we we can live with 99.5% shortest repr coverage, or maybe the complexity is worth it. I just want to record the issues here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12450>
_______________________________________

From report at bugs.python.org  Thu Jun 30 12:05:37 2011
From: report at bugs.python.org (=?utf-8?b?VG9tYcW+IMWgb2xj?=)
Date: Thu, 30 Jun 2011 10:05:37 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1309428337.09.0.842472815121.issue6721@psf.upfronthosting.co.za>


Toma? ?olc <tomaz.solc at tablix.org> added the comment:

The way I see it is that Charles-Fran?ois' patch trades a possibility of a deadlock for a possibility of a child process running with inconsistent states due to forcibly reinitialized locks.

Personally, I would rather have an occasional deadlock than an occasional random crash.

I don't like increasing complexity with fine-grained locking either. While the general case is unsolvable what Giovanni proposed at least solves the specific case where only the basic IO code is involved after a fork. In hindsight the only real life use-case I can find that it would solve is doing an exec() right after a fork().

There are quite a few bugs in the tracker that seem to have this same root cause, so it appears the impossibility of cleanly handling threads and forks is not something people are generally aware of. Since I think we agree you can't just disable fork() when multiple threads are running, how about at least issuing a warning in that case? That would be a two-line change in threading.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu Jun 30 13:17:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 11:17:01 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1309432621.72.0.68617489569.issue7117@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/issue7117>
_______________________________________

From report at bugs.python.org  Thu Jun 30 13:25:41 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 30 Jun 2011 11:25:41 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1309433141.0.0.775499030842.issue11682@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Renaud has updated the patch on bitbucket to incorporate Greg's tests (still in golden output form, but in a unittest/regrtest compatible way). That's a good enough starting point for me - they can be refactored into proper assert based tests later.

The only tweak needed is to explicitly save and restore stdout and stderr, since restoring the OS level ones often does the wrong thing when running the regression test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Thu Jun 30 14:10:02 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 30 Jun 2011 12:10:02 +0000
Subject: [issue12450] Use the Grisu algorithms to convert floats to strings
In-Reply-To: <1309421957.37.0.89091198831.issue12450@psf.upfronthosting.co.za>
Message-ID: <1309435802.21.0.516571432015.issue12450@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, I don't think this is worth further disruption.  We already have an excellent set of float repr routines.  There is no problem to be solved here.

----------
assignee:  -> rhettinger
priority: normal -> low
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12450>
_______________________________________

From report at bugs.python.org  Thu Jun 30 14:20:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 12:20:51 +0000
Subject: [issue12451] open: avoid the locale encoding when possible
In-Reply-To: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>
Message-ID: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

open() uses the locale encoding in Python 3 when opening text file if the encoding argument is not specified (implicit). Some functions use locale encoding, but it's not the right encoding. I see at least three cases where the encoding should be changed:

 - UTF-8 should be used instead for portability: it's a bug in the module
 - ASCII must be used instead: the module doesn't support non-ASCII characters (old file formats, old network protocols, some fields of a document, etc.)
 - ASCII can be used instead: it's just a micro-optimization, the ASCII encoding is  a little bit faster

To detect the usage of the implicit locale encoding, some functions can be monkeypatched:

 - builtins.open, io.open, _pyio.open
 - io.TextIOWrapper, _pyio.TextIOWrapper
 - more functions using directly or indirectly open/TextIOWrapper may be patched to emit the warning earlier

Attached open_hook.patch implements these hooks (hacks?) in the site module: it emits a ResourceWarning. Use python -Werror to raise an error if the locale encoding is used implicitly. If you really want to use the locale encoding, use encoding='locale' to make quiet the warning.

Quite all functions in Python uses the implicit locale encoding. For example, Python doesn't start with the patch and -Werror. If you use -Werror, you have to patch *all* calls to open()/TextIOWrapper to be able to locate real bugs, or the program will stop before hitting the real problems. Each time you have to check what is the real expected encoding, it takes a lot of time.

I started this huge project. I'm using ASCII most of the time (especially in Python tests), I don't know if it's correct. It will require a second step to ensure that the function really don't use/support non-ASCII characters.

I will use this issue for my commits, attach patches, and more generally discuss this topic.

----------
components: Unicode
files: open_hook.patch
keywords: patch
messages: 139473
nosy: haypo
priority: normal
severity: normal
status: open
title: open: avoid the locale encoding when possible
versions: Python 3.3
Added file: http://bugs.python.org/file22520/open_hook.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12451>
_______________________________________

From report at bugs.python.org  Thu Jun 30 14:55:57 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 30 Jun 2011 12:55:57 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1309428337.09.0.842472815121.issue6721@psf.upfronthosting.co.za>
Message-ID: <BANLkTin+1vDCCKjc-LkBhcG1mMQU+ypiRg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> The way I see it is that Charles-Fran?ois' patch trades a possibility of a deadlock for a possibility of a child process running with inconsistent states due to forcibly reinitialized locks.
>

Yeah, that's why I let this stale: that's really an unsolvable problem
in the general case. Don't mix fork() and threads, that's it.

> I don't like increasing complexity with fine-grained locking either. While the general case is unsolvable what Giovanni proposed at least solves the specific case where only the basic IO code is involved after a fork. In hindsight the only real life use-case I can find that it would solve is doing an exec() right after a fork().
>

Antoine seems to think that you can't release the I/O locks around I/O
syscalls (when the GIL is released). But I'm sure that if you come up
with a working patch it'll get considered for inclusion ;-)

> Since I think we agree you can't just disable fork() when multiple threads are running, how about at least issuing a warning in that case? That would be a two-line change in threading.py.

You mean a runtime warning? That would be ugly and clumsy.
A warning is probably a good idea, but it should be added somewhere in
os.fork() and threading documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu Jun 30 15:10:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Jun 2011 13:10:57 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <1309439457.77.0.206237779682.issue12442@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why do you return a percentage? People can compute that themselves if they want to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12442>
_______________________________________

From report at bugs.python.org  Thu Jun 30 15:15:14 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 30 Jun 2011 13:15:14 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <1309439714.23.0.803361956538.issue12442@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Agreed. I think we should pass on the raw data - how the user wants to format and present that is up to them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12442>
_______________________________________

From report at bugs.python.org  Thu Jun 30 15:42:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 30 Jun 2011 13:42:03 +0000
Subject: [issue12451] open: avoid the locale encoding when possible
In-Reply-To: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>
Message-ID: <E1QcHVJ-0004EY-UJ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bd73edea78dc by Victor Stinner in branch '3.2':
Issue #12451: distutils now opens the setup script in binary mode to read the
http://hg.python.org/cpython/rev/bd73edea78dc

New changeset 8a7fd54cba01 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12451: distutils now opens the setup script in binary mode
http://hg.python.org/cpython/rev/8a7fd54cba01

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12451>
_______________________________________

From report at bugs.python.org  Thu Jun 30 15:56:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 13:56:28 +0000
Subject: [issue12450] Use the Grisu algorithms to convert floats to strings
In-Reply-To: <1309421957.37.0.89091198831.issue12450@psf.upfronthosting.co.za>
Message-ID: <1309442188.06.0.0152555998765.issue12450@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/issue12450>
_______________________________________

From report at bugs.python.org  Thu Jun 30 16:00:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 30 Jun 2011 14:00:05 +0000
Subject: [issue12451] open: avoid the locale encoding when possible
In-Reply-To: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>
Message-ID: <E1QcHmm-0005rY-1m@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1942f7c8f51c by Victor Stinner in branch '3.2':
Issue #12451: pydoc.synopsis() now reads the encoding cookie if available, to
http://hg.python.org/cpython/rev/1942f7c8f51c

New changeset 3e627877b5a9 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12451: pydoc.synopsis() now reads the encoding cookie if
http://hg.python.org/cpython/rev/3e627877b5a9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12451>
_______________________________________

From report at bugs.python.org  Thu Jun 30 16:03:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Jun 2011 14:03:28 +0000
Subject: [issue12449] Add accelerator "F" to button "Finish" in all MSI
	installers made by bdist_msi
In-Reply-To: <1309419118.82.0.901696442421.issue12449@psf.upfronthosting.co.za>
Message-ID: <1309442608.3.0.408433518648.issue12449@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

As a new feature, this cannot go into distutils.

Would you like to contribute a patch?  I have currently no idea about the workings of the MSI code.

----------
components: +Distutils2 -Distutils
nosy: +alexis
stage:  -> needs patch
type: behavior -> feature request
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12449>
_______________________________________

From report at bugs.python.org  Thu Jun 30 16:10:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 30 Jun 2011 14:10:35 +0000
Subject: [issue12448] smtplib's __main__ doesn't flush when prompting
In-Reply-To: <1309414826.92.0.939740795599.issue12448@psf.upfronthosting.co.za>
Message-ID: <1309443035.31.0.874397818706.issue12448@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/issue12448>
_______________________________________

From report at bugs.python.org  Thu Jun 30 16:16:33 2011
From: report at bugs.python.org (Nir Aides)
Date: Thu, 30 Jun 2011 14:16:33 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1309443393.6.0.626834234358.issue6721@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Well, I ping my view that we should:

1) Add general atfork() mechanism.
2) Dive into the std lib and add handlers one by one, that depending on case, either do the lock/init thing or just init the state of the library to some valid state in the child.

Once this mechanism is in place and committed with a few obvious handlers such as the one for the logging library, other handlers can be added over time.

Following this path we will slowly resolve the problem, handler by handler, without introducing the invalid state problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu Jun 30 16:39:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 14:39:21 +0000
Subject: [issue12452] reuse plistlib in sysconfig;
	deprecation process in plistlib
In-Reply-To: <1309444761.1.0.605266895542.issue12452@psf.upfronthosting.co.za>
Message-ID: <1309444761.1.0.605266895542.issue12452@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

sysconfig uses regex to parse the a .plist file (format based on XML), /System/Library/CoreServices/SystemVersion.plist: the plistlib module can be used instead. I rebuild my patched Python from scatch (make distclean) and I didn't notice any bootstrap issue. The platform module does already use plistlib to parse SystemVersion.plist.
=> sysconfig_plistlib.patch

I also noticed that Plist and Dict emit PendingDeprecationWarning since Python 3.1. It's maybe time to switch to DeprecationWarning? test_plistlib doesn't use these classes, and there are not documented.
=> plistlib_deprecation.patch

----------
components: Library (Lib)
files: sysconfig_plistlib.patch
keywords: patch
messages: 139481
nosy: haypo
priority: normal
severity: normal
status: open
title: reuse plistlib in sysconfig; deprecation process in plistlib
versions: Python 3.3
Added file: http://bugs.python.org/file22521/sysconfig_plistlib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12452>
_______________________________________

From report at bugs.python.org  Thu Jun 30 16:39:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 14:39:30 +0000
Subject: [issue12452] reuse plistlib in sysconfig;
	deprecation process in plistlib
In-Reply-To: <1309444761.1.0.605266895542.issue12452@psf.upfronthosting.co.za>
Message-ID: <1309444770.06.0.317672307476.issue12452@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file22522/plistlib_deprecation.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12452>
_______________________________________

From report at bugs.python.org  Thu Jun 30 16:44:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 30 Jun 2011 14:44:49 +0000
Subject: [issue12452] reuse plistlib in sysconfig;
	deprecation process in plistlib
In-Reply-To: <1309444761.1.0.605266895542.issue12452@psf.upfronthosting.co.za>
Message-ID: <1309445089.73.0.64914919929.issue12452@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/issue12452>
_______________________________________

From report at bugs.python.org  Thu Jun 30 16:52:24 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 30 Jun 2011 14:52:24 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1309445544.48.0.441057050971.issue2193@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, it's been a while since I looked at the cookie code, and I didn't review it when I reviewed your patch.  But some time after I hit submit on my message the issue about some stuff getting ignored anyway occurred to me.  So given that we are *already* in that situation, applying your patch to avoid bailing on only some invalid cookies makes sense to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Thu Jun 30 16:54:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 14:54:50 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1309445690.08.0.845227428963.issue9561@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

pkginfo_utf8.patch: distutils uses UTF-8 to write PKG-INFO and .egg-info, instead of the locale encoding. It should be applied to 2.7, 3.2 and 3.3.

packaging_pkginfo_utf8.patch: packaging tests use UTF-8 to write PKG-INFO files, instead of the locale encoding (cosmetic change, the file content is an empty string :-)). It should only be applied to 3.3 (packaging has been introduced in Python 3.3).

----------
keywords: +patch
versions:  -Python 3.1
Added file: http://bugs.python.org/file22523/pkginfo_utf8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Thu Jun 30 16:55:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 14:55:03 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1309445703.64.0.880353439482.issue9561@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file22524/packaging_pkginfo_utf8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Thu Jun 30 17:00:10 2011
From: report at bugs.python.org (Julian)
Date: Thu, 30 Jun 2011 15:00:10 +0000
Subject: [issue12445] dict view values objects are missing tp_richcmp and
	tp_as_number
In-Reply-To: <1309392190.89.0.80399053449.issue12445@psf.upfronthosting.co.za>
Message-ID: <1309446010.67.0.809213292049.issue12445@psf.upfronthosting.co.za>


Julian <Julian+Python.org at GrayVines.com> added the comment:

Looking over this again with a clear head, adding the number operators is the incorrect thing to do here I think, since that function was also written assuming we had a set-like view object as input.

I am inclined to think that the correct behavior here for those operators is to not change that function, but to not make values objects add-able at all, even with other values objects, which would probably be the only other logical choice,  so leaving that as it was before (but still making the equality change).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12445>
_______________________________________

From report at bugs.python.org  Thu Jun 30 17:04:08 2011
From: report at bugs.python.org (=?utf-8?b?VG9tYcW+IMWgb2xj?=)
Date: Thu, 30 Jun 2011 15:04:08 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1309446248.54.0.197690969309.issue6721@psf.upfronthosting.co.za>


Toma? ?olc <tomaz.solc at tablix.org> added the comment:

> You mean a runtime warning? That would be ugly and clumsy.
> A warning is probably a good idea, but it should be added somewhere in
os.fork() and threading documentation.

I was thinking about a run time warning that is emitted if you call os.fork() while multiple threads are active. It is ugly, but at least it tells you you are doing something that will in most cases not work correctly. I certainly agree that a warning should also be added to os.fork() documentation.

I'm attaching an example patch that adds it into _after_fork() in threading.py, but there are a number of other places where it might go instead. 

I believe that the comp.programming.threads post from David Butenhof linked above explains why adding atfork() handlers isn't going to solve this.

----------
Added file: http://bugs.python.org/file22525/emit_warning_on_fork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu Jun 30 17:08:00 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 30 Jun 2011 15:08:00 +0000
Subject: [issue7846] Fnmatch cache is never cleared during usage
In-Reply-To: <1265209336.56.0.865162695939.issue7846@psf.upfronthosting.co.za>
Message-ID: <1309446480.54.0.726515518587.issue7846@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, it's unnoficially configurable pre-3.2 (set _MAXCACHE on the module).  The lru_cache implementation doesn't have such an undocumented way of tweaking the limit.  In neither case, however, is it true that "nothing is ever cached".  You are saying that you are dealing with more than 100 patterns in a single application?  (256 if you are using 3.2, and in that case it is an LRU cache and so should perform well unless your more-than-256 patterns are used in a cyclical fashion.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7846>
_______________________________________

From report at bugs.python.org  Thu Jun 30 17:08:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Jun 2011 15:08:32 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1309446512.2.0.665674860406.issue9561@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> pkginfo_utf8.patch: distutils uses UTF-8 to write PKG-INFO and
> .egg-info, instead of the locale encoding. It should be applied to
> 2.7, 3.2 and 3.3.

Okay.  I guess you?ll use codecs.open in 2.7; please make sure there is no bootstrapping issue for the build of CPython itself.

It would be a good thing to have non-ASCII in the PGK-INFO/METADATA files in the tests; it?s how we caught #12320.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Thu Jun 30 17:08:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Jun 2011 15:08:49 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1309446248.54.0.197690969309.issue6721@psf.upfronthosting.co.za>
Message-ID: <1309446488.3214.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I was thinking about a run time warning that is emitted if you call
> os.fork() while multiple threads are active. It is ugly, but at least
> it tells you you are doing something that will in most cases not work
> correctly.

The problem is that multiprocessing itself, by construction, uses fork()
with multiple threads. Perhaps there's a way to use only non-blocking
communication instead (rendering the helper threads useless), but that's
not a trivial change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu Jun 30 17:10:11 2011
From: report at bugs.python.org (Nir Aides)
Date: Thu, 30 Jun 2011 15:10:11 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1309446611.99.0.528307762992.issue6721@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

> I believe that the comp.programming.threads post from 
> David Butenhof linked above explains why adding atfork() 
> handlers isn't going to solve this.

In Python atfork() handlers will never run from signal handlers, and if I understood correctly, Charles-Fran?ois described a way to "re-initialize" a Python lock safely under that assumption.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu Jun 30 17:11:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Jun 2011 15:11:23 +0000
Subject: [issue12444] accept sets or collections for str.strip/lstrip/rstrip
In-Reply-To: <1309380997.61.0.864474637719.issue12444@psf.upfronthosting.co.za>
Message-ID: <1309446683.21.0.828470617543.issue12444@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agreed with Raymond.  Is there some way the doc could be improved, or do we just close this report?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12444>
_______________________________________

From report at bugs.python.org  Thu Jun 30 17:13:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 15:13:24 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1309446804.89.0.13532431002.issue11873@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> What about Windows? tempfile.mkdtemp(prefix='bar') can generate
> ...\tmpxxbaxx\...

AH! The test failed on "x86 XP-4 x86":

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4874/steps/test/logs/stdio

======================================================================
FAIL: test_regexp (test.test_compileall.CommandLineTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_compileall.py", line 253, in test_regexp
    self.assertCompiled(self.initfn)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\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

@r.david.murray: would you like to fix the regex?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11873>
_______________________________________

From report at bugs.python.org  Thu Jun 30 17:16:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 15:16:21 +0000
Subject: [issue12453] test_import.test_failing_import_sticks() sporadic
	failures
In-Reply-To: <1309446981.3.0.601023155331.issue12453@psf.upfronthosting.co.za>
Message-ID: <1309446981.3.0.601023155331.issue12453@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The following test fails sometimes. I don't know on which buildbot it occurs. The last failure is on "x86 XP-5 3.x":

======================================================================
FAIL: test_failing_import_sticks (test.test_import.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_import.py", line 185, in test_failing_import_sticks
    self.assertRaises(ZeroDivisionError, __import__, TESTFN)
AssertionError: ZeroDivisionError not raised by __import__

http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/3085/steps/test/logs/stdio

----------
components: Tests
messages: 139492
nosy: haypo
priority: normal
severity: normal
status: open
title: test_import.test_failing_import_sticks() sporadic failures
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12453>
_______________________________________

From report at bugs.python.org  Thu Jun 30 17:21:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 15:21:46 +0000
Subject: [issue12139] Add CCC command support to ftplib
In-Reply-To: <1306001340.71.0.345746598563.issue12139@psf.upfronthosting.co.za>
Message-ID: <1309447306.64.0.259131660029.issue12139@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The test is still failing on many buildbots.

x86 Ubuntu Shared 3.x:

======================================================================
ERROR: test_ccc (test.test_ftplib.TestTLS_FTPClass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_ftplib.py", line 890, in test_ccc
    self.client.sendcmd('noop')
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/ftplib.py", line 261, in sendcmd
    return self.getresp()
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/ftplib.py", line 236, in getresp
    raise error_proto(resp)
ftplib.error_proto: 
 ?e?c???Z?8N?????

"PPC Tiger 3.x", "AMD64 Leopard 3.x", "x86 FreeBSD 6.4 3.x" and "x86 Tiger 3.x":

======================================================================
ERROR: test_ccc (test.test_ftplib.TestTLS_FTPClass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/test/test_ftplib.py", line 890, in test_ccc
    self.client.sendcmd('noop')
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/ftplib.py", line 261, in sendcmd
    return self.getresp()
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/ftplib.py", line 226, in getresp
    resp = self.getmultiline()
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/ftplib.py", line 212, in getmultiline
    line = self.getline()
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/ftplib.py", line 199, in getline
    line = self.file.readline()
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/socket.py", line 279, in readinto
    return self._sock.recv_into(b)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/ssl.py", line 392, in recv_into
    return socket.recv_into(self, buffer, nbytes, flags)
socket.timeout: timed out

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12139>
_______________________________________

From report at bugs.python.org  Thu Jun 30 17:38:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 30 Jun 2011 15:38:58 +0000
Subject: [issue7846] Fnmatch cache is never cleared during usage
In-Reply-To: <1265209336.56.0.865162695939.issue7846@psf.upfronthosting.co.za>
Message-ID: <1309448338.51.0.859460896664.issue7846@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Grr.  "it is *not* true that nothing is ever cached".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7846>
_______________________________________

From report at bugs.python.org  Thu Jun 30 17:39:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 30 Jun 2011 15:39:52 +0000
Subject: [issue12451] open: avoid the locale encoding when possible
In-Reply-To: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>
Message-ID: <E1QcJLB-0007Rh-Ko@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bafc5c7d24b2 by Victor Stinner in branch '3.2':
Issue #12451: doctest.debug_script() doesn't create a temporary file anymore to
http://hg.python.org/cpython/rev/bafc5c7d24b2

New changeset 77c589b27e90 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12451: doctest.debug_script() doesn't create a temporary
http://hg.python.org/cpython/rev/77c589b27e90

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12451>
_______________________________________

From report at bugs.python.org  Thu Jun 30 17:41:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 15:41:26 +0000
Subject: [issue12451] open: avoid the locale encoding when possible
In-Reply-To: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>
Message-ID: <1309448486.08.0.887103147663.issue12451@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #9561 for distutils: I just attached a new patch for PKG-INFO / .egg-info files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12451>
_______________________________________

From report at bugs.python.org  Thu Jun 30 18:05:40 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Thu, 30 Jun 2011 16:05:40 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1309449940.12.0.492868549719.issue11873@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


----------
nosy: +Thomas.Holmes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11873>
_______________________________________

From report at bugs.python.org  Thu Jun 30 18:11:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 30 Jun 2011 16:11:26 +0000
Subject: [issue12451] open: avoid the locale encoding when possible
In-Reply-To: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>
Message-ID: <E1QcJpt-0002Cr-7c@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 45e3dafb3dbe by Victor Stinner in branch '3.2':
Issue #12451: The XInclude default loader of xml.etree now decodes files from
http://hg.python.org/cpython/rev/45e3dafb3dbe

New changeset e8eea84a90dc by Victor Stinner in branch 'default':
(merge 3.2) Issue #12451: The XInclude default loader of xml.etree now decodes
http://hg.python.org/cpython/rev/e8eea84a90dc

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12451>
_______________________________________

From report at bugs.python.org  Thu Jun 30 18:21:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 30 Jun 2011 16:21:46 +0000
Subject: [issue12451] open: avoid the locale encoding when possible
In-Reply-To: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>
Message-ID: <E1QcJzt-000381-0D@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 68bc1a29ba5a by Victor Stinner in branch '3.2':
Issue #12451: Open files in binary mode in some tests when the text file is not
http://hg.python.org/cpython/rev/68bc1a29ba5a

New changeset 3969b6377f52 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12451: Open files in binary mode in some tests when the text
http://hg.python.org/cpython/rev/3969b6377f52

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12451>
_______________________________________

From report at bugs.python.org  Thu Jun 30 18:25:26 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 30 Jun 2011 16:25:26 +0000
Subject: [issue12139] Add CCC command support to ftplib
In-Reply-To: <1306001340.71.0.345746598563.issue12139@psf.upfronthosting.co.za>
Message-ID: <1309451126.73.0.918090350973.issue12139@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

The culprit here is the dummy FTP test server which does not complete the SSL shutdown procedure successfully.

I believe it's better if we remove the self.client.sendcmd('noop') line.

That's there in order to check that client and server can still "talk" after reverting the connection back to clear-text, but making the server doing this right is quite complicated, see for example:
http://code.google.com/p/pyftpdlib/source/browse/trunk/pyftpdlib/contrib/handlers.py?spec=svn868&r=861#196

I don't want to include and maintain that monster into test_ftplib.py so I think I'll just remove that line from the tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12139>
_______________________________________

From report at bugs.python.org  Thu Jun 30 18:25:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 30 Jun 2011 16:25:29 +0000
Subject: [issue12451] open: avoid the locale encoding when possible
In-Reply-To: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>
Message-ID: <E1QcK3U-0003TB-61@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c4388478f9b2 by Victor Stinner in branch 'default':
Issue #12451: Open the test file in binary mode in test_bz2, the text file is
http://hg.python.org/cpython/rev/c4388478f9b2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12451>
_______________________________________

From report at bugs.python.org  Thu Jun 30 18:34:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 30 Jun 2011 16:34:53 +0000
Subject: [issue12139] Add CCC command support to ftplib
In-Reply-To: <1306001340.71.0.345746598563.issue12139@psf.upfronthosting.co.za>
Message-ID: <E1QcKCZ-0004Lc-LE@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0cef8cac71c8 by Giampaolo Rodola' in branch 'default':
Issue 12139: ftplib - remove 'post CCC' test to fix various buildot failures due to dummy test server not properly handling SSL shutdown(), see http://bugs.python.org/msg139499
http://hg.python.org/cpython/rev/0cef8cac71c8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12139>
_______________________________________

From report at bugs.python.org  Thu Jun 30 18:35:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 16:35:53 +0000
Subject: [issue12454] mailbox: use ASCII to read/write .mh_sequences files
In-Reply-To: <1309451753.0.0.932089944066.issue12454@psf.upfronthosting.co.za>
Message-ID: <1309451753.0.0.932089944066.issue12454@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The MH class uses the locale encoding to read and write .mh_sequences files. According to R. David Murray, ASCII can be safetly used instead. Extract of our discussion on IRC:

bitdancer> haypo: that's one of the cases where using locale
           is probably correct, even though I'd rather it
           used utf-8.
bitdancer> haypo: for nmh it is ASCII, for whatever that is worth.
bitdancer> I base this on the fact that the pick command says
           that a utf-8 character is invalid.
bitdancer> for a sequence name.
bitdancer> Which is the only thing other than numbers that goes
           in a sequences files.
Jerub> I concurr (was reading code)

----------
components: Library (Lib)
files: mailbox.patch
keywords: patch
messages: 139502
nosy: haypo, r.david.murray
priority: normal
severity: normal
status: open
title: mailbox: use ASCII to read/write .mh_sequences files
versions: Python 3.3
Added file: http://bugs.python.org/file22526/mailbox.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12454>
_______________________________________

From report at bugs.python.org  Thu Jun 30 18:36:03 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 30 Jun 2011 16:36:03 +0000
Subject: [issue12139] Add CCC command support to ftplib
In-Reply-To: <1306001340.71.0.345746598563.issue12139@psf.upfronthosting.co.za>
Message-ID: <1309451763.18.0.277350810603.issue12139@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12139>
_______________________________________

From report at bugs.python.org  Thu Jun 30 18:36:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 16:36:08 +0000
Subject: [issue12454] mailbox: use ASCII to read/write .mh_sequences files
In-Reply-To: <1309451753.0.0.932089944066.issue12454@psf.upfronthosting.co.za>
Message-ID: <1309451768.25.0.417794018955.issue12454@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +jerub

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12454>
_______________________________________

From report at bugs.python.org  Thu Jun 30 18:46:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 16:46:58 +0000
Subject: [issue12451] open: avoid the locale encoding when possible
In-Reply-To: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>
Message-ID: <1309452418.83.0.869164690229.issue12451@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #12454 for the mailbox module (.mh_sequences).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12451>
_______________________________________

From report at bugs.python.org  Thu Jun 30 18:51:16 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 30 Jun 2011 16:51:16 +0000
Subject: [issue12451] open: avoid the locale encoding when possible
In-Reply-To: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>
Message-ID: <1309452676.84.0.990875933624.issue12451@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/issue12451>
_______________________________________

From report at bugs.python.org  Thu Jun 30 19:04:14 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Thu, 30 Jun 2011 17:04:14 +0000
Subject: [issue12449] Add accelerator "F" to button "Finish" in all MSI
	installers made by bdist_msi
In-Reply-To: <1309419118.82.0.901696442421.issue12449@psf.upfronthosting.co.za>
Message-ID: <1309453454.58.0.00838758377255.issue12449@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


----------
nosy: +thomas.holmes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12449>
_______________________________________

From report at bugs.python.org  Thu Jun 30 19:06:03 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Thu, 30 Jun 2011 17:06:03 +0000
Subject: [issue8501] --dry-run option doesn't work
In-Reply-To: <1271972145.51.0.00309332974734.issue8501@psf.upfronthosting.co.za>
Message-ID: <1309453563.55.0.652909195117.issue8501@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


----------
nosy: +thomas.holmes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8501>
_______________________________________

From report at bugs.python.org  Thu Jun 30 19:08:24 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Thu, 30 Jun 2011 17:08:24 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1309453704.17.0.415748671341.issue828450@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


----------
nosy: +thomas.holmes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Thu Jun 30 19:46:11 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 30 Jun 2011 17:46:11 +0000
Subject: [issue12444] accept sets or collections for str.strip/lstrip/rstrip
In-Reply-To: <1309380997.61.0.864474637719.issue12444@psf.upfronthosting.co.za>
Message-ID: <1309455971.79.0.0834616371726.issue12444@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The docs are clear on this topic.  No doc change can help someone who skips reading the docs and assumes the method does something different.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12444>
_______________________________________

From report at bugs.python.org  Thu Jun 30 19:58:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Jun 2011 17:58:24 +0000
Subject: [issue9504] signal.signal/signal.alarm not working as expected
In-Reply-To: <1280910836.88.0.645209486589.issue9504@psf.upfronthosting.co.za>
Message-ID: <1309456704.12.0.036152011415.issue9504@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: pitrou -> 
stage: patch review -> needs patch
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9504>
_______________________________________

From report at bugs.python.org  Thu Jun 30 20:03:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 30 Jun 2011 18:03:39 +0000
Subject: [issue12407] test_subinterps fails on Windows
In-Reply-To: <1308999728.78.0.684048233766.issue12407@psf.upfronthosting.co.za>
Message-ID: <E1QcLaT-00048H-QO@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7c60c1b41da9 by Antoine Pitrou in branch '3.2':
Issue #12407: Explicitly skip test_capi.EmbeddingTest under Windows.
http://hg.python.org/cpython/rev/7c60c1b41da9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12407>
_______________________________________

From report at bugs.python.org  Thu Jun 30 20:05:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 30 Jun 2011 18:05:07 +0000
Subject: [issue12407] test_subinterps fails on Windows
In-Reply-To: <1308999728.78.0.684048233766.issue12407@psf.upfronthosting.co.za>
Message-ID: <E1QcLbt-0004KK-L8@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5cae52417b9d by Antoine Pitrou in branch 'default':
Issue #12407: Explicitly skip test_capi.EmbeddingTest under Windows.
http://hg.python.org/cpython/rev/5cae52417b9d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12407>
_______________________________________

From report at bugs.python.org  Thu Jun 30 20:06:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Jun 2011 18:06:05 +0000
Subject: [issue12407] test_subinterps fails on Windows
In-Reply-To: <1308999728.78.0.684048233766.issue12407@psf.upfronthosting.co.za>
Message-ID: <1309457165.16.0.0787698551579.issue12407@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed, thank you.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12407>
_______________________________________

From report at bugs.python.org  Thu Jun 30 20:22:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Jun 2011 18:22:22 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1309458142.65.0.160576633248.issue12291@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think the question is: will the slowdown apply to module import, or only to explicit uses of the marshal module? If the latter, then I think we can live with it - we discourage using marshal as a general-purpose serialization scheme anyway.

As for the patch:
- why do the tests have to carry a large chunk of binary data? if some data is needed, at least it would be nice if it were kept small
- not sure either why it needs zlib and base64; just use the repr() of the bytestring
- "assertEqual = self.assertEqual" is more of a nuisance than anything else; you're making the code more complicated to read just to save a few keystrokes; same for "assertIsInstance = self.assertIsInstance"
- can you add a comment next to the fields you're adding to the marshal C struct?
- if the "r_byte" macro isn't used anymore, it should be removed, not commented out
- in r_string(), what happens if PyBytes_Check(data) is false? there should probably be a TypeError of some sort
- in r_string() again, if data is NULL after the read() call, the exception shouldn't be shadowed by an EOFError
- why do you call read(1) at the beginning? it seems to make the code more complicated for no useful purpose

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Thu Jun 30 20:37:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Jun 2011 18:37:01 +0000
Subject: [issue7123] Multiprocess Process does not always exit when run from a
	thread.
In-Reply-To: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
Message-ID: <1309459021.42.0.716579033701.issue7123@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7123>
_______________________________________

From report at bugs.python.org  Thu Jun 30 21:05:28 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 30 Jun 2011 19:05:28 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1309446488.3214.6.camel@localhost.localdomain>
Message-ID: <20110630190521.GA41324@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

My suggestion to this would be that it should be outdated in the
same way that Georg Brandl has suggested for changing the default
encoding on python-dev [1], and add clear documentation on that,
also in respect to the transition phase ..

> The problem is that multiprocessing itself, by construction,
> uses fork() with multiple threads.

.. and maybe add some switches which allow usage of fork() for the
time being.

Today a '$ grep -Fir fork' does not show up threading.rst at all,
which seems to be little in regard to the great problem.
I would add a big fat note that multiprocessing.Process should be
used instead today, because how about those of us who are not
sophisticated enough to be appointed to standard committees?

But anyway we should be lucky: fork(2) is UNIX specific, and thus
it can be expected that all thread-safe libraries etc. are aware of
the fact that they may be cloned by it.  Except mine, of course.  ,~)

[1] http://mail.python.org/pipermail/python-dev/2011-June/112126.html
--
Ciao, Steffen
sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu Jun 30 21:12:51 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 30 Jun 2011 19:12:51 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1309458142.65.0.160576633248.issue12291@psf.upfronthosting.co.za>
Message-ID: <1309461169.39295.YahooMailRC@web25805.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> I  think the question is: will the slowdown apply to module import, or only to  
>explicit uses of the marshal module? If the latter, then I think we can live  
>with it - we discourage using marshal as a general-purpose serialization scheme  
>anyway.

Thanks for reviewing the patch.

As to your point  - agreed, and as the marshal code is completely broken now, 
something that works is an improvement, even if it's slower than optimal. If 
that turns out to be a problem in practice, it can be fixed.

> As for the patch:
> - why do the tests have to carry a large  chunk of binary data? if some data is 
>needed, at least it would be nice if it  were kept small

Agreed, I just used the initial file where I had the problem - didn't know where 
the problem was, initially. Will look at reducing this.

> - not sure either why it needs zlib and base64; just use the  repr() of the 
>bytestring

The original data was 53K, so just the repr of the bytestring of the raw data is 
around 150K. If I zip the data, it's about 4K, but the repr of that data is 
around 12K. The base64/zlibbed version is 5K.

This will be less of an issue when the test data size is reduced.

> - "assertEqual = self.assertEqual" is more of a  nuisance than anything else; 
>you're making the code more complicated to read  just to save a few keystrokes; 
>same for "assertIsInstance =  self.assertIsInstance"

I'm not sure how it's more complicated or harder to understand. I didn't do it 
just to save keystrokes when writing, it's also to avoid noise when reading. IMO 
this is a question of personal taste, or is this approach proscribed somewhere? 
I've certainly seen it in other Python code.

> - can you add a comment next to the fields you're  adding to the marshal C 
>struct?

Yes, will do.

> - if the "r_byte" macro isn't used anymore,  it should be removed, not 
>commented out

The commenting out is a temporary measure, the comment will be removed before 
commit.

> - in r_string(), what happens if  PyBytes_Check(data) is false? there should 
>probably be a TypeError of some  sort

There is a PyBytes_Check in marshal_load which raises a TypeError if it fails. 
The PyBytes_Check in r_string is only called in the path from marshal_load 
(because p->readable is only non-NULL in that path) - so for the failure to 
occur one would need an initial read to deliver bytes, and a subsequent read to 
deliver non-bytes. Still, I have no problem adding a TypeError raising in 
r_string if PyBytes_Check fails.

> - in r_string() again, if data is NULL after the read() call, the  exception 
>shouldn't be shadowed by an EOFError

Good point, I aim to fix this by changing the lower condition to

if (!PyErr_Occurred() && (read < n)) { ... }

which should be sufficient - do you agree?

> - why do you call read(1) at  the beginning? it seems to make the code more 
>complicated for no useful  purpose

I gave the reasoning in the comment just above the read(1). I agree it makes it 
a little more complicated, but not onerously so - and the approach fails fast as 
well as allowing operation with any stream, not just random-seekable ones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Thu Jun 30 21:14:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Jun 2011 19:14:15 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <20110630190521.GA41324@sherwood.local>
Message-ID: <1309461214.3214.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I would add a big fat note that multiprocessing.Process should be
> used instead today, because how about those of us who are not
> sophisticated enough to be appointed to standard committees?

How do you think multiprocessing.Process launches a new process?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu Jun 30 21:23:38 2011
From: report at bugs.python.org (Cal Leeming)
Date: Thu, 30 Jun 2011 19:23:38 +0000
Subject: [issue12455] urllib2 Request() forces capitalize() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>


New submission from Cal Leeming <cal.leeming at simplicitymedialtd.co.uk>:

I came up against a problem today whilst trying to submit a request to a remote API. The header needed to contain:

'Content-MD5' : "md5here"

But the urllib2 Request() forces capitalize() on all header names, and transformed it into "Content-Md5", which in turn made the remote web server ignore the header and break the request (as the remote side is case sensitive, of which we don't have any control over).

I attempted to get smart by using the following patch:
class _str(str):
    def capitalize(s):
        print s
        return s

_headers = {_str("Content-MD5") : 'md5here'}

But this failed to work:


---HEADERS---
{'Content-MD5': 'nts0yj7AdzJALyNOxafDyA=='}

---URLLIB2 DEBUG---
send: 'POST /api/v1 m HTTP/1.1\r\nContent-Md5: nts0yj7AdzJALyNOxafDyA==\r\n\r\n\r\n'

Upon inspecting the urllib2.py source, I found 3 references to capitalize() which seem to cause this problem, but it seems impossible to monkey patch, nor fix without forking.

Therefore, I'd like to +1 a feature request to have an extra option at the time of the request being opened, to bypass the capitalize() on header names (maybe, header_keep_original = True or something). 

And, if anyone could suggest a possible monkey patch (which doesn't involve forking huge chunks of code), that'd be good too :)

Thanks

Cal

----------
components: Library (Lib)
messages: 139512
nosy: Cal.Leeming
priority: normal
severity: normal
status: open
title: urllib2 Request() forces capitalize() on header names, breaking some requests
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12455>
_______________________________________

From report at bugs.python.org  Thu Jun 30 21:26:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Jun 2011 19:26:10 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1309461169.39295.YahooMailRC@web25805.mail.ukl.yahoo.com>
Message-ID: <1309461928.3214.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > - "assertEqual = self.assertEqual" is more of a  nuisance than anything else; 
> >you're making the code more complicated to read  just to save a few keystrokes; 
> >same for "assertIsInstance =  self.assertIsInstance"
> 
> I'm not sure how it's more complicated or harder to understand. I didn't do it 
> just to save keystrokes when writing, it's also to avoid noise when reading. IMO 
> this is a question of personal taste, or is this approach proscribed somewhere? 

It's not proscribed, but trying to remove the "self." because it's
supposed to be more readable is a bit of a strange thing to do.
Also, people reading the test suite should be accustomed to
"self.assertEqual" anyway, so there's no point trying to hide it.

> > - in r_string(), what happens if  PyBytes_Check(data) is false? there should 
> >probably be a TypeError of some  sort
> 
> There is a PyBytes_Check in marshal_load which raises a TypeError if it fails. 
> The PyBytes_Check in r_string is only called in the path from marshal_load 
> (because p->readable is only non-NULL in that path) - so for the failure to 
> occur one would need an initial read to deliver bytes, and a subsequent read to 
> deliver non-bytes. Still, I have no problem adding a TypeError raising in 
> r_string if PyBytes_Check fails.

Error checking can't just be probabilistic. Perhaps there's a bug in the
file-like object; or perhaps it is a non-blocking IO object and read()
will return None at times.

> > - why do you call read(1) at  the beginning? it seems to make the code more 
> >complicated for no useful  purpose
> 
> I gave the reasoning in the comment just above the read(1). I agree it makes it 
> a little more complicated, but not onerously so - and the approach fails fast as 
> well as allowing operation with any stream, not just random-seekable ones.

Well, it wouldn't fail any slower if you didn't do it, since you need to
call read() very soon anyway (presumably as part of the same call to
marshal.load()). Failing "fast" doesn't seem to bring anything here. My
vote is for removing the complication.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12291>
_______________________________________

From report at bugs.python.org  Thu Jun 30 21:33:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 30 Jun 2011 19:33:47 +0000
Subject: [issue12455] urllib2 Request() forces capitalize() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1309462427.93.0.64737904474.issue12455@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, three occurrences means you only have three methods to patch (and two of them are trivial).  But I agree that copying the non-trivial method doesn't look fun from a maintenance perspective.

You could also try using an object that is not a subclass of str.  The problem with subclassing str is that some (most?) string methods do not do a subclass check but directly call the C implementation of the method.  I think there's an issue in the tracker somewhere about that.

The problem with not subclassing string, of course, is that you may end up implementing a lot of methods on your object to get it to play nicely with urllib2's assumption that it *is* a string.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12455>
_______________________________________

From report at bugs.python.org  Thu Jun 30 21:39:53 2011
From: report at bugs.python.org (Cal Leeming)
Date: Thu, 30 Jun 2011 19:39:53 +0000
Subject: [issue12455] urllib2 Request() forces capitalize() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1309462793.26.0.295451194415.issue12455@psf.upfronthosting.co.za>


Cal Leeming <cal.leeming at simplicitymedialtd.co.uk> added the comment:

Sorry, I should clarify.. The str() patch worked, but it failed to work within the realm of urllib2:


s = _str("Content-MD5")
print "Builtin:"
print "plain:       %s" % ( s )
print "capitalized: %s" % ( s.capitalize() )

s = str("Content-MD5")
print "Builtin:"
print "plain:       %s" % ( s )
print "capitalized: %s" % ( s.capitalize() )

Builtin:
plain:       Content-MD5
capitalized: Content-MD5
Builtin:
plain:       Content-MD5
capitalized: Content-md5

Why it works in the unit test, and not within urllib2, is totally beyond me. Especially since I put a debug call on the method, and it does get called.. yet urllib2 debug still shows it sending the wrong value.

---
capitalize() bypassed: sending value: Content-MD5
send: 'POST /api/url\r\nContent-Md5: nts0yj7AdzJALyNOxafDyA==\r\n\r\n'
---

I have a feeling that the problem may lie somewhere after the opener (like HTTPConnection or AbstractHTTPHandler), rather than the urllib2 calls to capitalize(), but not having much luck monkey patching those :X

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12455>
_______________________________________

From report at bugs.python.org  Thu Jun 30 21:50:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 30 Jun 2011 19:50:53 +0000
Subject: [issue12455] urllib2 Request() forces capitalize() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1309463453.18.0.922168322964.issue12455@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, judging by your test it isn't capitalize that's the issue.  capitalize produces Content-md5, whereas debug is showing urllib2 sending Content-Md5.  So something else is massaging the header name on send.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12455>
_______________________________________

From report at bugs.python.org  Thu Jun 30 21:53:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 19:53:36 +0000
Subject: [issue5120] Disabling test_ttk_guionly on mac
In-Reply-To: <1233437150.39.0.445953575427.issue5120@psf.upfronthosting.co.za>
Message-ID: <1309463616.35.0.502506126965.issue5120@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Still crashing on "PPC Tiger 3.x" buildbot:
----------------
...
[333/356/2] test_ttk_guionly
Fatal Python error: Segmentation fault

Current thread 0xa000ed88:
  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 1063 in runtest_inner
  File "./Lib/test/regrtest.py", line 861 in runtest
  File "./Lib/test/regrtest.py", line 669 in main
  File "./Lib/test/regrtest.py", line 1648 in <module>
make: *** [buildbottest] Segmentation fault
----------------

http://www.python.org/dev/buildbot/all/builders/PPC%20Tiger%203.x/builds/2109/steps/test/logs/stdio

Can anyone with a Mac look at this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5120>
_______________________________________

From report at bugs.python.org  Thu Jun 30 21:53:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 19:53:39 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309463619.1.0.026986641352.issue8716@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_ttk_guionly is still crashing regulary on "PPC Tiger 3.x" buildbot, see issue #5120. Can anyone with a Mac look at this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8716>
_______________________________________

From report at bugs.python.org  Thu Jun 30 22:08:48 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 30 Jun 2011 20:08:48 +0000
Subject: [issue12452] reuse plistlib in sysconfig;
	deprecation process in plistlib
In-Reply-To: <1309444761.1.0.605266895542.issue12452@psf.upfronthosting.co.za>
Message-ID: <1309464528.57.0.0260778818087.issue12452@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12452>
_______________________________________

From report at bugs.python.org  Thu Jun 30 22:17:21 2011
From: report at bugs.python.org (Cal Leeming)
Date: Thu, 30 Jun 2011 20:17:21 +0000
Subject: [issue12455] urllib2 Request() forces capitalize() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1309465041.05.0.198959183233.issue12455@psf.upfronthosting.co.za>


Cal Leeming <cal.leeming at simplicitymedialtd.co.uk> added the comment:

(short answer, I found the cause, and a suitable monkey patch) - below are details of how I did it and steps I took.

-----

Okay so I forked AbstractHTTPHandler() then patched do_request_(), at which point "request.headers" and request.header_items() have the correct header name (Content-MD5).

So I tried this:
opener = urllib2.build_opener(urllib2.HTTPHandler(debuglevel=1))
opener.addheaders = [("Content-TE5", 'test'), ]

However the headers came back capitalized, so the problem is happening somewhere after addheaders. 


 > grep -R "addheaders" *.py
urllib.py:        self.addheaders = [('User-Agent', self.version)]
urllib.py:        self.addheaders.append(args)
urllib.py:        for args in self.addheaders: h.putheader(*args)
urllib.py:            for args in self.addheaders: h.putheader(*args)
urllib2.py:        self.addheaders = [('User-agent', client_version)]
urllib2.py:        for name, value in self.parent.addheaders:

> grep -R "def putheader" *.py
httplib.py:    def putheader(self, header, value):
httplib.py:    def putheader(self, header, *values):

I also then found: http://stackoverflow.com/questions/3278418/testing-urllib2-application-http-responses-loaded-from-files

I then patched this:

            class HTTPConnection(httplib.HTTPConnection):
                def putheader(self, header, value):
                    print [header, value]

This in turn brought back:
['Content-Md5', 'nts0yj7AdzJALyNOxafDyA==']

Which means it's happening before putheader(). So I patched _send_request() on HTTPConnection(), and that also brought back 'Content-Md5'. Exception trace shows:

  File "/ddcms/dev/webapp/../webapp/sites/ma/management/commands/ddcms.py", line 147, in _send_request
    _res = opener.open(req)
  -- CORRECT --
  File "/usr/local/lib/python2.6/urllib2.py", line 391, in open
    response = self._open(req, data)
  -- CORRECT --
  File "/usr/local/lib/python2.6/urllib2.py", line 409, in _open
    '_open', req)
  -- CORRECT --
  File "/usr/local/lib/python2.6/urllib2.py", line 369, in _call_chain
    result = func(*args)
  -- CORRECT --
  File "/ddcms/dev/webapp/../webapp/sites/ma/management/commands/ddcms.py", line 126, in http_open
    return self.do_open(HTTPConnection, req)
  -- CORRECT --
  File "/usr/local/lib/python2.6/urllib2.py", line 1142, in do_open
    h.request(req.get_method(), req.get_selector(), req.data, headers)
  -- INVALID --
  File "/usr/local/lib/python2.6/httplib.py", line 914, in request
    self._send_request(method, url, body, headers)
  File "/ddcms/dev/webapp/../webapp/sites/ma/management/commands/ddcms.py", line 122, in _send_request
    raise


The line that causes it?

                    headers = dict(
                        (name.title(), val) for name, val in headers.items())
                    
So it would appear that title() also needs monkey patching.. Patched to use:


# Patch case sensitive headers (due to reflected API being non RFC compliant, and
# urllib2 not giving the option to choose between the two)
class _str(str):
    def capitalize(s):
        print "capitalize() bypassed: sending value: %s" % ( s )
        return s
    
    def title(s):
        print "title() bypassed: sending value: %s" % ( s )
        return s

_headers = {_str('Content-MD5') : _md5_content}

capitalize() bypassed: sending value: Content-MD5
title() bypassed: sending value: Content-MD5
send: 'POST /url/api HTTP/1.1\r\nContent-MD5: nts0yj7AdzJALyNOxafDyA==\r\n\r\n'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12455>
_______________________________________

From report at bugs.python.org  Thu Jun 30 22:19:39 2011
From: report at bugs.python.org (Cal Leeming)
Date: Thu, 30 Jun 2011 20:19:39 +0000
Subject: [issue12455] urllib2 Request() forces capitalize() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1309465179.31.0.627720828955.issue12455@psf.upfronthosting.co.za>


Cal Leeming <cal.leeming at simplicitymedialtd.co.uk> added the comment:

So @r.david.murray, it would appear you were right :D Really, I should have looped through each method on str(), and wrapped them all to see which were being called, but lesson learned I guess.

Sooo, I guess now the question is, can we possibly get a vote on having a feature which disables this functionality from the opener level. Something like:
opener = urllib2.build_opener(urllib2.HTTPHandler(debuglevel=1, keep_original_header_case=True))

But obviously a less tedious attribute name :)

In the mean times, if anyone else comes up against this problem, the code I pasted above will work fine for now.

Cal

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12455>
_______________________________________

From report at bugs.python.org  Thu Jun 30 22:25:56 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 30 Jun 2011 20:25:56 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1309461214.3214.9.camel@localhost.localdomain>
Message-ID: <20110630202547.GA63317@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

> How do you think multiprocessing.Process launches a new process?

But it's a single piece of code under control and even
multi-OS/multi-architecture test-coverage, not a general purpose
"Joe, you may just go that way and Python will handle it
correctly"?

What i mean is: ten years ago (or so), Java did not offer true
selection on sockets (unless i'm mistaken) - servers needed a 1:1
mapping of threads:sockets to handle connections?!
But then, a "this thread has finished the I/O, let's use it for
something different" seems to be pretty obvious.
This is ok if it's your professor who is forcefully misleading
you into the wrong direction, but otherwise you will have
problems, maybe sooner, maybe later (, maybe never).  And
currently there is not a single piece of documentation which
points you onto the problems.  (And there *are* really people
without Google.)

The problem is that it looks so simple and easy - but it's not.
In my eyes it's an unsolvable problem.  And for the sake of
resource usage, simplicity and execution speed i appreciate all
solutions which don't try to do the impossible.

I want to add that all this does not really help just as long just
*any* facility which is used by Python *itself* is not under control
of atfork.  Solaris e.g. uses atfork for it's memory allocator,
because that is surely needed if anything else but async-safe
facilities are used in the newly forked process.  Can Python give
that guarantee for all POSIX systems it supports?

Good night.
--
Ciao, Steffen
sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu Jun 30 22:53:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Jun 2011 20:53:14 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <20110630202547.GA63317@sherwood.local>
Message-ID: <1309467152.3214.16.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > How do you think multiprocessing.Process launches a new process?
> 
> But it's a single piece of code under control and even
> multi-OS/multi-architecture test-coverage, not a general purpose
> "Joe, you may just go that way and Python will handle it
> correctly"?

Sorry, how does that make the problem any different?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu Jun 30 22:53:45 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 30 Jun 2011 20:53:45 +0000
Subject: [issue12455] urllib2 forces title() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1309467225.73.0.897419857559.issue12455@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

A feature request for a way to control this is reasonable.  However, new features can only go into 3.3.

----------
stage:  -> needs patch
title: urllib2 Request() forces capitalize() on header names, breaking some requests -> urllib2 forces title() on header names, breaking some requests
type: behavior -> feature request
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12455>
_______________________________________

From report at bugs.python.org  Thu Jun 30 23:00:41 2011
From: report at bugs.python.org (Cal Leeming)
Date: Thu, 30 Jun 2011 21:00:41 +0000
Subject: [issue12455] urllib2 forces title() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1309467641.34.0.852934159217.issue12455@psf.upfronthosting.co.za>


Cal Leeming <cal.leeming at simplicitymedialtd.co.uk> added the comment:

Damn 3.3 huh? Ah well, at least it's in the pipeline ^_^

Thanks for your help on this @r.david.murray!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12455>
_______________________________________

From report at bugs.python.org  Thu Jun 30 23:26:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 30 Jun 2011 21:26:01 +0000
Subject: [issue12451] open: avoid the locale encoding when possible
In-Reply-To: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>
Message-ID: <E1QcOkJ-0006oD-Mr@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0c49260e85a0 by Victor Stinner in branch 'default':
Issue #12451: Add support.create_empty_file()
http://hg.python.org/cpython/rev/0c49260e85a0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12451>
_______________________________________

From report at bugs.python.org  Thu Jun 30 23:28:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 21:28:12 +0000
Subject: [issue11999] sporadic failure in test_mailbox
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <1309469292.19.0.795001122875.issue11999@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Now we see if the buildbots agree with me that this is fixed.

There is a new failure today on a Windows Seven buildbot:

======================================================================
FAIL: test_reread (test.test_mailbox.TestMaildir)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_mailbox.py", line 900, in test_reread
    self.assertFalse(refreshed())
AssertionError: True is not false

http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/3353/steps/test/logs/stdio

----------
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11999>
_______________________________________